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^GRAPHICAL USER INTERFACE FOR AUTOMATED PROCESS CONTROL 

CROSS-REFERENCES TO RELATED APPLICATIONS 

The present application is a continuation-in-part of U.S. patent application 
09/930,698, Ran J. Flam, System and method for automated process control, filed 
8/15/2001, which in turn claims priority from U.S. provisional application 
60/225,532, Ran J. Flam, System and method for automated process scheduling, filed 
8/16/2000. The CIP contains the entire Detailed Description of USSN 09/930,698; 
the material added in the CIP includes material in the section Details of 
administrative query execution and all of the material in the sections beginning 
with the section Details of the GUI for defining and modifying administrative queries. 

FIELD OF THE INVENTION 

This invention relates to the field of process control, and more particularly 
to techniques for using a database system to implement a table-driven process 
control system. 



BACKGROUND OF THE INVENTION 

To date, the use of computers in process control systems has typically 
been limited to employing a calendar-date activation system that reminds the 
operator when an activity is due to be performed. Conventional process control 
systems suffer from a major drawback. Typically, they rely on a singular input, 
such as calendar date and time, and require human interaction to respond to 
such events and their recurrence and to make decisions and take action 
accordingly; an example of such a system is Outlook, manufactured by Microsoft 
Corporation, with its reminder capability. 
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Other systems have filters which can account for a given set of conditions 
and take actions accordingly; an example of such a system is the AR System by 
Remedy Corporation. Even though that system can monitor for multiple pre- 
defined conditions in the process and can schedule the monitoring and any 
5 actions taken in response to the monitoring, the scheduling is limited to 
scheduling a single occurrence of the monitoring and the associated actions at a 
predetermined date or time or at a recurring fixed time interval. Furthermore, 
although this system has the ability to detect a recurring match of a given set of 
conditions so that additional, and possibly different, actions can be taken based 
10 on a time interval, as is required when a problem persists and must be escalated, 
the users can neither configure the time intervals nor the actions themselves; 
rather they can only select from a fixed set of component choices. The 
components themselves are not user-definable, and therefore limit the 
extensibility of the escalation functionality. 

15 Available systems are further limited to doing their monitoring at 

infrequent intervals, since the monitor always has the same response to a given 
condition. If the monitoring is done frequently, say every 10 minutes, the result 
is a flood of redundant responsive actions unless the output of responsive actions 
is simply curtailed after a fixed number has been sent over a given period of 

20 time. Neither infrequent monitoring nor ignoring the monitoring is conducive to 
the timely detection of events and conditions in a process that is being controlled. 

Moreover, existing systems lack the ability to perform responsive actions 
based on an overall count of process records matching a given set of conditions, 
and beyond that, they lack the ability to respond to trends over time with regard 
25 to such counts. Existing systems are therefore unable to provide proactive 
responses that can eliminate the need to take corrective actions. 

Although computer programs can always be developed to implement 
responses to specific conditions arising during a process and to particular 
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sequences of conditions, such programs are of limited use, as they require code 
changes whenever new conditions and new requirements arise. Moreover, 
program code is by its nature general, and user-made modifications to a process 
control system's code can have consequences for the system that go far beyond 
5 what the user intended. 

Because of these deficiencies, there are presently no process control 
systems available that are able to control processes that require many different 
process-related criteria to be continuously monitored and actions taken in 
response thereto at pre-determined times and time intervals and where the 
10 conditions justifying a certain action may vary substantially from one process to 
another, as may the need to respond to a persistent set of conditions. Moreover, 
such process control systems as have been devised to monitor complex processes 
are not easily or safely configurable or modifiable by their users. 

It is therefore an object of the present invention to overcome the above 
15 described deficiencies: to eliminate the dependency of such systems on human 
operators; to allow frequent monitoring of conditions and selective execution of 
responsive actions to occur at predetermined times and time intervals; to provide 
timely responses; to automatically detect states of persistent conditions and 
execute different actions as needed, based on the recurrence of given conditions, 
20 and based on elapsed time between responsive actions; to provide the ability to 
take responsive actions based on trends, so that such actions are proactive, rather 
than reactive; and finally, to configure a system that performs such monitoring 
and executes responsive actions in a safe and user-friendly manner and thereby 
reducing the need to use skilled people to adjust a process control system to 
25 evolving needs in a timely way. 
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SUMMARY OF THE INVENTION 

One of the major contributors to achieving the foregoing object of the 
invention is the graphical user interface that system 801 uses to define and 
modify administrative queries, and in particular the graphical user interface that 
5 system 801 uses to define and modify the actions performed by an administrative 
activity. This graphical user interface is a window which contains a table that in 
turn contains an entry for the field in the PR record upon which the action is to 
be performed when the PR record is returned by an administrative query. The 
entry includes a first field which identifies the field in the PR record to be acted 
10 on and one or more action fields that, when the user has selected the entry, the 
user may set to specify the action. 

In other aspects of the invention, there is a window for each of the kinds 
of actions that may be performed by an administrative activity, and the kind of 
15 action determines what action fields are in an entry for a field. One kind of 
action that may be defined is setting, clearing, or incrementing a field. Values of 
fields that may be incremented must belong to an ordered set of values. What 
an action does may further depend on whether the field to which it is applied 
has a null value or another value. 

20 

An action may also obtain a value for the field to which the action is 
applied from another field in the PR record. This other field is termed a reference 
field. The action may simply assign the reference field's value at the time the 
action is performed to the field to which the action is applied or it may modify 
25 the value before assigning it. In the case of actions on fields with time values, the 
modification may increase or decrease the time value obtained from the reference 
field, may specify the kind of time units to use, and when the units are days, may 
specify whether the computation is to use calendar days or business days. 
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When the action is on a field that takes a person value, the value may be 
set from a role field. The role field provides a person value from an ordered set 
of person values; state associated with the role field specifies the last value 
provided, and the role field provides the next value in the ordered set to the field 
5 the action is on. 

The foregoing and other objects and advantages of the invention will be 
apparent to those skilled in the arts to which the invention pertains upon perusal 
of the following Detailed Description and drawing, wherein: 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a flowchart depicting the steps by which an exemplary 
embodiment of the present invention operates. 

15 FIG. 2 shows a flowchart depicting how administrative activities are 

configured in an exemplary embodiment of the present invention. 

FIG. 3 shows a flowchart depicting how administrative queries are 
configured in an exemplary embodiment of the present invention. 

FIG. 4 shows a flowchart depicting the steps by which an exemplary 
20 embodiment of the present invention executes administrative queries. 

FIG. 5 shows a flowchart depicting the steps by which an exemplary 
embodiment of the present invention processes a result set. 

FIG. 6 is a first entity-relation diagram showing relationships between 
database tables in the present invention. 

25 FIG. 7 is a second entity-relation diagram showing relationships between 

database tables in the present invention. 
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FIG. 8 is an overview of an implementation of the process control system 
of the present invention. 

FIG. 9 shows the top-level window used to make or modify an 
administrative query. 

5 FIG. 10 shows windows used to specify an administrative query's scope. 

FIG. 11 shows windows used to schedule an administrative query. 

FIG. 12 shows the window used to define or modify an administrative 
query's administrative activity. 

FIG. 13 shows windows used to define an AA_set_values action. 

10 FIG. 14 shows windows used to define an AA_set _dates action. 

FIG. 15 shows windows used to define an AA_set_person action. 

FIG. 16 shows windows used to define an AA_post_activities action. 

FIG. 17 shows windows used to define an administrative query. 



15 

In the following discussion, reference numbers are used to refer to 
components of the invention. Each reference number has two parts: the 
rightmost two digits are a number within a figure; the remaining digits are a 
figure number. The figure number is the number of the figure in which the 
20 component first appears. Thus, the first appearance of a component with the 
reference number 203 will be in FIG. 2 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

The following Detailed Description will begin with an overview of a process 
25 control system in which the invention is embodied, continue with a detailed 
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description of the tables belonging to the process control system and the 
relationships between them, thereupon provide a detailed description of the 
operation of the process control system, and will finally describe the graphical 
user interface of the invention. 

5 

Overview of the process control system in which the invention is embodied-FIG. 
8 

FIG. 8 shows an overview of an embodiment of automated process control 
system 801 that is constructed according to the principles of the invention. The 
10 embodiment is used to control business processes such as handling orders or 
customer complaints, but the techniques of the invention can be employed 
equally well in systems that control industrial or technical processes such as oil 
refining, electric power generation, or telephone or packet switching. 

System 801 is implemented using a standard computer 803 that is 
15 connected to a standard database system 825. In a preferred embodiment, the 
database system is a relational database system made by Oracle Corporation, of 
Redwood City, California. Standard computer 803 has a processor 805 which is 
connected to Internet 807 and to local peripheral devices 808 as well as to 
database system 825. Processor 805 has a memory 809 (understood to include 
20 both physical and virtual memory) which includes code executed by processor 
809. Of interest to the present discussion is standard operating system code 811, 
Internet code 815, for performing functions such as email and interacting with 
Web pages according to the HTTP protocol, Database code 813, which is part of 
and controls the operation of database system 825, and process control code 817, 
25 which is application code that implements the process control system. Process 
control code 817 uses components of the operating system 811, Internet code 815, 
and DB code 813 to interact with Internet 807, local peripheral devices 808, and 
DB system 825. With regard to the interaction with DB system 825, process 
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control code 817 issues queries to DB system 825 and receives the results of the 
queries from DB system 825. 

In broad terms, process control system 801 works by making records of 
processes that are being controlled in a table in database system 825 and using 
5 predefined queries that are stored in a table database system 825 to repeatedly 
query the table and perform activities that are predefined for the query on the 
result set of records returned by the query. The repeated queries are executed 
automatically by system 801. The predefined and automatically executed queries 
are termed herein administrative queries. An activity is made up of a number of 

10 predefined actions, and when the activity is performed, system 801 executes its 
actions. The activities to be performed by an administrative query, as well as an 
activity's actions, are also defined by entries in tables in the database system, and 
log tables in the database system determine the state of a process record returned 
by the administrative query with regard to that execution of the administrative 

15 query. When an execution of a query returns a process record, system 801 uses 
the state information to determine what activity is to be performed with regard 
to the process record. 

Current schedule table 823 in memory 809 contains an entry for each 
administrative query which system 801 is repeatedly executing; the entry for the 

20 query in table 823 includes the time for the next execution of the query by system 
801. Current query and processing plans table 824 is an optimization; when 
system 801 begins execution of an administrative query, it reads the information 
needed to execute the administrative query and perform any activities associated 
with it from the records in database system 825 that define the query and the 

25 activities and stores the information in table 824, where it is quickly and easily 
available to system 801 for use during the execution of the administrative query. 
Tables 823 and 824 are updated whenever system 801 checks database system 
825 and finds that configuration tables have changed; such update of table 823 
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and 824 is then performed based on the configuration information fetched from 
database system 825. 

As would be expected from the above overview, database system 825 
includes PR tables 827, which are the tables that contain the records for the 
5 processes, PR activity tables 835, containing records that define and log the 
activities, action tables 857, whose records define the actions that make up an 
activity, and administrative query tables 845, which define the administrative 
queries that system 801 may execute on the PR tables 827. The definition of an 
administrative query includes the query, one or more activities to be performed, 

10 and the intervals at which the administrative query is to be made. Log tables 
871 keep track of the state of a process with regard to a query and also chart 
trends in the processes being controlled. Log tables 871 and program sequence 
855 together permit the activity that is performed when a query finds a PR record 
to be selected according to the state of the PR record with regard to the current 

1 5 execution of the administrative query. 

To give a concrete example, one type of process that can be controlled by 
system 801 is a customer complaint. The exemplary process for dealing with a 
customer complaint is to assign it to a customer complaint specialist. The 
customer complaint specialist is to investigate the complaint and reply to the 

20 customer within a set time period. If the reply is not timely, the complaint is 
escalated to the customer complaint specialist's supervisor, again with a time 
limit for the supervisor to deal with the problem. The activity that corresponds 
to the escalation is the dispatch of an email message to the supervisor. In system 
801, when the complaint arrives, a PR record for the complaint is made in a table 

25 in PR tables 827. When the complaint specialist replies to the customer, the PR 
record is altered to indicate that the complaint specialist has replied and the time 
of the reply. System 801 periodically runs a query contained in administrative 
query tables 845 which queries PR table 833 for PR records that indicate that the 
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complaint specialist has not timely replied. The query further specifies that 
when the complaint specialist has not timely replied, the activity to be performed 
is to escalate the complaint by sending email to the supervisor. When system 801 
finds such a record, it performs the specified activity, as defined by records in PR 
5 activity tables 835 and in action tables 857. System 801 records the time at which 
the query was run, the fact that the PR record was found and the activity 
performed in log tables 871. As will be explained in detail later, one function of 
log tables 871 is to record the state of a process with regard to a given PR record 
and a given execution of a query and to permit different executions of the given 

10 query to result in different activities being performed for the given PR record, 
depending on the state of the process. For instance, once the escalation is 
recorded in the log tables with regard to the query and the PR record, further 
executions of the query will not result in repeated escalation activities. In the 
terminology that is used in the following, once the query has resulted in the 

15 performance of the escalation activity for the given PR record, the given PR 
record is in a state of Persistent Conditions with regard to the query and because 
the given PR record is in the state of Persistent Conditions, the escalation activity 
is not repeated. 

The use of tables in DB system 825 to determine the behavior of the 
20 process control system makes system 801 highly configurable, but limits the 
configurability so that it can be safely done by non-technical users of system 801. 
All of the tools provided by DB system 825 for configuring entries in its tables are 
available to configure the entries in the tables of system 825, as are the user 
interfaces which DB system 825 provides for those tools. These user interfaces 
25 strongly limit the amount of damage that can be done to the tables, and thereby 
to system 801, by an unskilled user. For example, only a system manager may be 
permitted to define tables or add tables to or delete them from the database; a 
less skilled user may be permitted only to add or delete records in existing tables, 
and a completely unskilled user may be permitted only to modify fields in 
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existing records. System 801 is made still more safe and easy to use by a 
graphical user interface that is implemented on top of the user interfaces 
provided by DB system 825. Using the graphical user interface, the user of the 
system can define PR records as required for the occurrences that are important 

5 to his or her processes, can define his or her own PR activities in PR activity 
tables 835, can define his or her own queries in administrative query tables 845, 
including the activities to be performed in response to the queries, and can define 
an activity's actions in detail in action tables 857. What can be done by a given 
action is limited by the form of its record in the action table to which it belongs, 

10 and this, too, greatly contributes to the safety with which system administrative 
queries can be configured. In defining the activities to be performed, the user 
can further define states for the process represented by the record and the 
activities to be performed in the various states. Both configuration and query 
execution are done by process control code 817, which accordingly includes an 

15 execution module 821, which executes queries and schedules next executions in 
current schedule table 823 and an admin module 819, which adds records to and 
deletes them from the tables and configures the individual records. System 801 
can run on a single computer 803, which functions as a server for the system, or 
alternatively it can run concurrently on a plurality of servers for load balancing 

20 purposes. 

Relationships between the tables in DB system 825: FIGs. 6 and 7 

FIGs 6 and 7 are entity-relationship diagrams which show relationships 
between the database tables of system 601 which are important in the present 
25 context. In relational database systems generally, tables are related to each other 
by values in the tables' records. For example, each record in a first table may 
have a record identifier field that contains a unique identifier for the record. 
Each record in a second table may have a record reference field that contains a 
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value which is one of the unique identifiers for the records in the first table. The 
unique identifier for a given record in the first table may be used in a query to 
locate records in the second table whose record reference field contains the given 
record. Similarly, the value of the record reference field may be used in a query 

5 to locate the record in the first table whose record identifier field has the value 
contained in the record reference field in the second table's record. It should be 
noted here that the relationships between records in tables may be one-to-many, 
as in the case of the relationship between a given record in the first table and the 
records in the second table whose record reference field contains the given 

10 record's unique identifier, or one-to-one, as is the relationship established by the 
unique identifier value between a given record in the second table and a record 
in the first table. 

In FIGs. 6 and 7, boxes representing the tables of FIG. 8 are connected by 
arrows that are labeled with the name of a field whose value is a unique 

15 identifier for a record in the table which is the source of the arrow. Values from 
that field also appear in the records of the table which is the destination of the 
arrow and relate those records to the record whose unique identifier they 
contain. The relationship between a record in the table which is the source of the 
arrow and records in the table which is the destination is generally one-to-many, 

20 but is in some cases one-to-one. 

These relationships between records in the tables are used to organize the 
data in the database. For example, in system 801, the records representing 
processes that are being controlled by system 801 are in PR table 833, which 
contains one record per process being controlled. In system 801, the user can 
25 group the records in PR 833 by project, and can group projects by division. The 
subdivision is done by means of Project table 831 and Division table 829. Each 
record in PR table 833 has a field, projected, whose value is an identifier for a 
record in Project table 831, and that record identifies the project that the record in 
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PR table 833 belongs to. Each record in Project table 831 has a field, division_id 
603, whose value identifies a record in Division table 829, and that record 
identifies the division that the record in Project table 831 belongs to. A query on 
PR table 833 by a given value of projected 605 will return all of the records in PR 
5 table 833 for processes that belong to that project. Project table 831 and Division 
table 829 are related in the same way by divisionjd 603. 

A set of relationships that is particularly important for the present 
discussion is the set of relationships between the tables PR 833, PR_activity 839, 
PR_activity_type 837, Admin_activity Jype 841, Action tables 857, Admin_query 

10 853, and Program_sequence 855. All of these tables have to do with the 
performance of activities for processes. There are two broad classes of activities- 
ones done by human users of system 801 and ones done by system 801 itself in 
connection with executions of administrative queries on PR table 833 that return 
non-empty result sets. The latter activities are termed administrative activities. 

15 The administrative activities are performed with reference to the PR records of 
the result sets. In the present context, we are primarily concerned with 
administrative activities. 

An important feature of system 801 is that a user can define his or her own 
activities. The mechanism for doing this is PR_activity_type table 837, whose 

20 records represent descriptions of activities. Each such description is termed 
herein a PR activity type. Fields in other tables of FIGs. 6 and 7 whose values are 
identifiers for PR_activity_type records have the name pr_activity_type, which 
appears at 609 in FIGs. 6 and 7. The PR_activity_type records that represent 
descriptions of administrative activities form a logical subtable of 

25 PR_activity_type table 837. This subtable appears as Admin_activity_type table 
841 in FIGs. 6-8. In the following, the descriptions in subtable 841 are termed 
herein Admin activity types. 



13 



spartaO 1.005 



An Admin activity type is effectively a kind of program for the 
administrative activity. When system 801 performs an administrative activity, it 
executes the Admin activity type for the administrative activity with regard to a 
specific PR record returned by an execution of an administrative query. One can 
5 thus speak of an execution of an Admin activity type with regard to a given PR 
record. As is generally the case with programs, the specific activity resulting 
from a given execution of an Admin activity type may depend not only on the 
Admin activity type, but also on values contained in the PR record with regard to 
which the Admin activity type is being executed. Which Admin activity type is 
10 selected for execution may further depend on the state of the given PR record 
with regard to the execution of the administrative query. 

When system 801 executes an Admin activity type, it performs one or 
more actions. Each of the actions is described in a record in action tables 857. 
Each record in action tables 857 is related to a specific Admin activity type by a 

15 field in the action table record whose value is the identifier for the Admin 
activity type's record in PR_activityJype table 841, as seen in FIG. 6. There can 
thus be many records in action tables 815 related to a given Administrative 
activity type. When the Administrative activity type is executed, all of the action 
table records related to the Administrative activity type are executed. The result 

20 of the execution of a given action table record may depend on values in the PR 
record with regard to which the Admin activity type is being executed. 

PR_activity table 839, finally, is a table whose records represent activities 
that have been performed or are scheduled to be performed with regard to a 
given PR record. Thus, as shown in FIG. 6, each PR_activity record includes a 
25 unique identifier (pr_id 607) for a record in PR 833 and a unique identifier 
(pr_activity_type 609) for the record in PR_activity_type table 837 that represents 
the PR activity type for the activity represented by the record. In the case of 
administrative activities, the record in PR_activity . table 839 represents the 
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activity which system 801 performs when it executes the Admin activity type 
specified by pr_activity_type 609 on the PR record specified by pr_id 607. 

As shown in FIG. 6, each record representing an administrative query in 
Admin_query table 853 includes a unique identifier for a record in 

5 PR_activity_type table 837. The record is the Admin activity type which system 
801 executes the first time the administrative query returns a given PR record to 
perform the initial administrative activity. It has already been indicated that 
when consecutive executions of the administrative query return the given PR 
record, the given PR record is in a state of Persistent Conditions with regard to 

10 the administrative query and on subsequent executions of the administrative 
query, system 801 may perform administrative activities other than the initial 
administrative activity with regard to the PR record. Administrative activity 
types for these other administrative activities are specified in records in 
Program_sequence table 855 that are associated with the administrative query, 

1 5 and accordingly, each of these records includes a unique identifier for a record in 
PR_activityJype table 853. 



Details of PR tables 827 

As already explained, there is a record in PR table 833 for each process 
20 being controlled by system 801, and Project table 831 and Division table 829 
organize the PR table records by project and the projects by divisions. 

PR table 833 

A record in PR table 833 looks like this: 

25 
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PR( 



10 



15 



20 



25 



id 


NUMBER (12) NOT NULL, 


project id 


NUMBER (12) , 


ref number 


VARCHAR2 (40) , 


name 


VARCHAR2 (80) , 


parent id 


NUMBER (12) , 


status type 


NUMBER ( 6 ) , 


category type 


NUMBER (6) , 


reason opened_type 


NUMBER (6) , 


priority type 


NUMBER ( 6 ) , 


severity type 


NUMBER (6) , 


exposure type 


NUMBER (6) , 


entity id 


NUMBER (12) , 


customer rel id 


NUMBER (12) , 


originator rel id 


NUMBER (12) , 


resDonsible rel id 


NUMBER (12) , 


recruired time 


NUMBER (10, 2) , 


recruired cost 


NUMBER (12, 2) , 


date opened 


DATE, 


date due 


DATE, 


date closed 


DATE, 


date last_activity 


DATE, 


date_current_state 


DATE, 


is_closed 


NUMBER ( 1 ) , 


date_created 


DATE NOT NULL, 


date_updated 


DATE NOT NULL, 


created_by_rel_id 


NUMBER (12) , 


upda t ed_by_r e l_i d 


NUMBER (12) , 


primary key (id) 





30 ) 



35 



PR table 833 contains all process records (PR records) in the database. The 
data fields in this table describe a process and contain such information as 
priority, customer and date due. A first group of the fields must appear in every 
PR record; other fields may be added as required by the application. The other 
fields in the present example offer a typical example of how a PR record may be 
configured. 



Essential fields 

40 The essential fields of a PR record are: (a) id: a unique ID for the record in 

this table, referred to in FIGs. 6 and 7 as pr_id 607, (b) projected: the ID of the 
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record in Project table 833 for the project that the project represented by the given 
PR record belongs to, (c) date_created: the exact date/ time that a given PR is 
created, i.e., that the given row into the PR has been inserted, (d) date_opened: 
the date/ time that the associated process, event, etc. should be associated with, 

5 e.g., the date/ time that a customer called with a request, (e) parent_id: the ID of a 
parent PR, if any, (f) status Jype: current status of the PR, e.g., "Opened", and 
"Work in Progress", (g) is_closed: a Boolean value indicating whether a PR is 
closed or is still active, (h) date_due: the date due for completing a process, i.e., 
date due for closing a PR, (i) created_by_j"el_id: a specific ID of a person who 

10 created the given PR record in the database, (j) originatorjreLid: a specific ID of 
a person who is considered the originator or the "sponsor" of the given PR, (k) 
responsible_rel_id: a person that is assigned to the given PR, referred to as the 
Assigned To, (1) updated_by_rel_id: a specific ID of a person that the given PR 
was last updated by, (m) date_current_state: a date/ time that the status of the 

15 given PR was last changed, (n) date_closed: a date/ time that the given PR was 
closed, if at all, (o) datejast_activity: a date/ time that a PR Activity was last 
performed for the given PR, (p) customerjreMd: a specific ID of a contact 
associated with the given PR, (q) entity_id: a specific ID of a company associated 
with the given PR, and (r) date_updated: a date and time that a given record in 

20 the PR table was last updated. 



Fields defined for a particular application 

The following additional PR data fields are examples of additional fields 
that can be defined as needed): (s) category_type: a value from a "Category" 
25 pick-list, with possible selections such as: "Hardware", "Software", and 
"Documentation", (t) reason_opened_type: a value from a "Reason Opened" 
pick-list, with possible selections such as: "Service Request", "Problem Report", 
and "Request for Information", (u) priorityjype: a value from a "Priority" pick- 

17 



spartaO 1.005 



list, with possible selections such as: "Low", "Medium", and "High", (v) 
severity _type: a value from a "Severity" pick-list, with possible selections such 
as: "Low", "Medium", and "High", (w) exposure_type: a value from an 
"Exposure" pick-list, with possible selections such as: "Limited", "All 
5 Customers", and "All Customers and Employees", (x) required_time: estimated 
time to complete the given PR, (y) required_cost: estimated time to complete the 
given PR. 



Project table 831 
10 A record in Project table 831 looks like this: 

Project ( 

id NUMBER (12) NOT NULL, 

name VARCHAR2(80) NOT NULL, 

division_id NUMBER (6) NOT NULL, 

15 project_type NUMBER (6) NOT NULL, 

created_by_rel_id NUMBER (12) NOT NULL, 

updated_by_rel_id NUMBER (12) NOT NULL, 

date_created DATE NOT NULL, 

date_updated DATE NOT NULL, 
20 primary key (id) 

) 

Project table 831 has a record for all of the projects defined for a given 
25 database. As described above, every PR record is associated with a given Project, 
and thus, it can be said that all PRs in a database are "grouped" by their 
respective Projects. Similarly, a Project is associated with a given record in 
Division table 829, and thus, it can be said that all Projects in a database are 
further "grouped" by their respective Divisions. 
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This table contains the following data fields: (a) id: a unique ID in this 
table, (b) name: Project name, e.g., "Customer Support", "R&D Work Items", and 
"Assembly Line Controls", (c) division_id: a specific Division ID that a given 
Project is associated with; thus enabling the grouping of Projects by Divisions, 
5 (d) project_type: a value from a "Project Type" pick-list, with possible selections 
such as: "Manufacturing", "Administrative", and "Human Resources", (e) 
created_by_rel_id: a specific ID of a person who created the given Project record 
in this table, (f) updated_by_rel_id: a specific ID of a person that last updated the 
given Project record in this table, (g) date_created: date/time that the given 
10 Project record was created in this table, (h) date_updated: the date and time that 
this record was last updated. 

Division table 829 

A division table record looks like this: 

1 5 Division ( 

id NUMBER (12) NOT NULL, 

name VARCHAR2(80) NOT NULL, 

created_by_rel_id NUMBER (12) NOT NULL, 
updated_by_rel_id NUMBER (12) NOT NULL, 
20 date_created DATE NOT NULL, 

date_updated DATE NOT NULL, 

primary key (id) 

) 

25 

The Division table is a table that contains all Divisions defined for a given 
database. A Division is a group of Projects, and a Project is a group of PRs. 
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This table contains the following data fields: (a) id: a unique ID in this 
table, (b) name: Division name, e.g., "California Site", and "New Jersey Site", (c) 
created_by_reMd: a specific ID of a person who created the given Project record 
in this table, (d) updated_by_rel_id: a specific ID of a person that last updated 
5 the given Project record in this table, (e) date_created: date/ time that the given 
Project record was created in this table, (f) date_updated: the date and time that 
this record was last updated. 



PR activity tables 835 

10 PR_activity type table 837 contains the PR activity types for the activities 

performed manually by users of system 801 or automatically by system 801 itself 
when an administrative query returns a non-empty result set. PR_activity table 
839 is the collection of all activities, of either class, that were performed or are 
scheduled to be performed for all the processes represented by PR records in PR 

15 table 833. 

PR_activity_type table 837 

A record in PR__activity_type table 837 looks like this: 
PR_activity_type ( 

id NUMBER (12) NOT NULL, 

20 is_admin NUMBER (1) NOT NULL, 

name . VARCHAR2 (80), 

can_schedule NUMBER (1) , 

min_members NUMBER (2) NOT NULL, 

require_summary NUMBER (1) NOT NULL, 

25 summary_prompt VARCHAR2 (12 0) , 

can_edit NUMBER (1) NOT NULL,-/ 

edit_summary_only NUMBER (1) NOT NULL, 

date_updated DATE NOT NULL, 

primary key (id) 



30 ) 



Each record in PR_activity Jype table 837 represents a PR activity type. If 
the value of the is_admin field is 1, the record belongs to Admin_activity_type 
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subtable 841 and represents an Admin activity type. The PR_activity table 
contains the following data fields: (a) id: a unique ID in this table, (which unique 
ID is referred to as pr_activity_type 609 by related tables seen in FIGs. 6 and 7), 
(b) is_admin, described above; (c) name: a specific name given to the PR Activity 
5 Type, e.g., "Call Customer", "Work Initiated", and "Close - Done", (d) 
can_schedule: if the value equals one, such a PR Activity Type can be scheduled 
by a user, otherwise, it can only be posted as a performed activity, (e) 
min_members: minimum number of activity participants that are required for 
the given PR Activity Type, (f) require_summary: if the value equals one, the 

10 given PR Activity Type can be performed only if an activity summary is entered, 
(g) can_edit: if the value equals one, a PR Activity performed using the given PR 
Activity Type can be edited, otherwise, it can not be edited at all, (h) 
edit_summary_only: if the value equals one, the summary of the PR Activity 
performed using the given PR Activity Type can be edited, otherwise, it can not 

15 be edited at all, and (i) date_updated: the date and time that this record was last 
updated. 

When a record represents an Admin_activity_type, some of the fields have 
special values: can_schedule is not relevant, it is actually set to zero (0). 
Similarly, min_members = 0, and require_summary and summary_prompt are 
20 set to "neutral", meaningless values. The field can_edit is set to 0, as is 
edit_summary_only. 

PR_activity table 839 

A record in PR_activity table 839 looks like this: 
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PRjictivity ( 



10 



15 



id 

pr_id 

pr_activity_type 

short_description 

summary 

date_posted 

date_scheduled 

date_per formed 

posted_by__rel_id 

upda t e d_by_r e 1_ i d 

responsible_rel_id 

status_origin 

status_af ter 

date_updated 

primary key (id) 



NUMBER (12) 
NUMBER (12) 
NUMBER ( 6 ) , 
VARCHAR2 (120) , 
LONG, 

DATE NOT NULL, 

DATE, 

DATE, 

NUMBER (12) 
NUMBER (12) 
NUMBER (12) , 
NUMBER ( 6 ) , 
NUMBER (6) , 
DATE NOT NULL, 



NOT NULL, 
NOT NULL, 



NOT NULL, 
NOT NULL, 



PR_activity table 839 is a table that contains records representing activities 

20 that are scheduled to be or have been performed for processes represented by PR 
records. Each record indicates the activity's PR_activity type and the PR record 
for the process. When a record is added to PR_activity table 839 as a result of 
the scheduling or performance of an activity for a process, the activity is said to 
have been posted. A PR activity record contains the following data fields: (a) id: 

25 a unique ID in this table, (b) pr_id: the ID of the record in PR table 833 with 
which this record is associated; (c) pr_activity_type: the identifier of a record in 
PR_activity_type table 837 that represents the activity's PR_activity type, (d) 
short_description: a short summary of the activity, e.g., "Called customer to 
clarify request", (e) summary: detailed description of the actions taken by the 

30 activity, (f) date_posted: date/ time that the given record in the PR_activity table 
was created, (g) date_scheduled: date/ time that the given PR Activity is 
scheduled to be performed, (h) date_performed: date/ time that the given PR 
Activity was performed; this value is null if not yet performed, i.e., if still 
scheduled, (i) posted_by_rel_id: a specific ID of a person who posted the given 

35 PR Activity, (j) updated_by_rel_id: a specific ID of a person who last updated the 
given PR Activity, (k) responsible_rel_id: a specific ID of a person that is 
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responsible for performing the given PR Activity, (1) status_prigin: a PR status 
that was in effect prior to performing the given PR Activity, e.g., "Opened", (m) 
status_after: a PR status that went into effect after performing the given PR 
Activity, e.g., "Work in Progress", and (n) date_updated: the date and time that 
5 this record was last updated. 

When the activity represented by a record in PR_activity table 837 is an 
administrative activity, posting occurs only after system 801 has performed the 
administrative activity. System 801 automatically sets many of the above data 
fields to special values when it posts the record. The date scheduled is set to 

10 null, the date_performed is the then date/ time that system 801 has posted the 
record, and the responsible_rel_id is set with a symbolic "admin" user, as is the 
posted jDy_rel_id. Summary is set with an indication that "this activity is an 
administrative activity posted due to certain conditions with regard to the PR. 
Also included in the summary is the PR_query. description, i.e., the value in the 

15 'description' field of the PR_query record for the administrative query whose 
execution caused the administrative action to be performed. 

Administrative query tables 845 

Admin_query table 853 contains a record for each of the administrative 
20 queries, referred to as Admin Query (AQ), which system 801 can make. An 
administrative query has the following components: 

• a query (the query is an SQL query in a preferred embodiment); 

• a scope specifier for the query. The scope specifier specifies a subset of 
the records in PR 833 over which the query will be run; 

25 • a schedule specifier for the query; this contains information that 

system 801 uses to figure out when the query is to be executed; 
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• an initial administrative activity specifier, which specifies an 
administrative activity which will be performed when a PR record 
which is returned by an execution of the administrative query is in the 
state of First Occurrence with regard to the execution of the 
5 administrative query. 

An administrative query is further associated with a program sequence that 
specifies administrative activities that are performed for returns of the specific 
record in PR 833 by executions of the administrative query for which the record 
is in the state of Persistent Conditions with regard to the execution. The states of 
10 Persistent Conditions and First Occurrence will be described in more detail in 
connection with the discussion of log tables 871. 

As shown in FIG. 6, the definition of each of the administrative query's 
components is contained in a record in another table that is referenced by the 
record in the Admin_query table 853; thus, the query is defined by a record in 

15 PR_query table 847, the scope by a record in AQ_scope table 849, the schedule by 
AQ_schedule table 851, and the initial administrative activity by the record in 
PR_activity_type table 837 for the initial administrative activity's Administrative 
activity type. One consequence of this arrangement is that queries, scopes, 
schedules, and Administrative activity types may be shared by any number of 

20 administrative queries, which greatly simplifies the configuration of 
administrative queries in system 801. Types of administrative activities which 
are performed when a PR record which is returned by an execution of an 
administrative query is in the state of Persistent Conditions with regard to that 
execution are specified in Program_sequence table 855. All of these tables will be 

25 described in detail in the following. 

Adminjquery table 853 

A record in Admin_query table 853 looks like this: 
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Admin query ( 



id NUMBER (12) NOT NULL, 

pr_query_id NUMBER (12) NOT NULL, 

aq_scope_id NUMBER ( 12 ) , 

5 aqLSchedule_id NUMBER (12) NOT NULL, 

pr_activity_type NUMBER (12) NOT NULL, 

aq_priority_type NUMBER (6) NOT NULL, 

is_active NUMBER (4) NOT NULL, 

date_updated DATE NOT NULL, 

10 primary key (id) 

) 

The Admin_query table specifies all the components of the Admin Query 
(AQ). This table contains the following data fields: (a) id: unique Admin Query 

15 ID, referred to as the AQ ID, (b) pr_query_id: the ID of the record for the query 
to be executed in PR_query 847, (c) aq_scope_id: the ID of record for the scope to 
be used in AQ_scope 849, (d) aq_schedule_id: the ID of the record for the 
schedule to be used in AQ_schedule 851, (e) pr_activity_type: the unique 
identifier for the initial activity's Admin activity type record in PR_activity_type 

20 table 837; (f) aq_priority_type: the Priority Group that this AQ should be 
executed under; the priority of the administrative query represented by this 
record is indicated by a value between 1 and 10 in this field; in single server 
systems, the priority decides the order in which a set of administrative queries 
that are scheduled to be executed at the same time are in fact executed; in 

25 multiple-server systems, the priority is also used to determine which servers 
execute which administrative queries; (g) is_active: indicates whether the given 
AQ is still active, i.e., should this AQ be considered for execution as scheduled, 
or is it a "retired" AQ, i.e. one that should no longer be executed, and (h) 
date_updated: the date and time that this record was last updated. It should also 

30 be noted that in other embodiments, the initial administrative activity might 
simply be the administrative activity specified in the first record in the query's 
program sequence. 
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PR_query table 847 



A record in PR_query table 847 looks like this: 



PR query ( 



10 



id 

name 

sql_f rom 
sql_where 
description 
date_updated 
primary key (id) 



NUMBER (12) NOT NULL, 
VARCHAR2(40) NOT NULL, 
VARCHAR2 (256) NOT NULL, 
LONG NOT NULL, 
VARCHAR2 (1024) , 
DATE NOT NULL, 



Administrative queries are SQL queries. PR_query table 847 specifies the 
SQL FROM, WHERE, and ORDER clauses of the SQL query. This table contains 
15 the following fields of data: (a) id: unique Query ID, (b) name: given Query 
name, (c) sql_from: the SQL FROM clause, (d) sqLwhere: the SQL WHERE 
clause, (e) description: the description (user language) of what the Query is 
about, and (f) date_updated: the date and time that this record was last updated. 

20 AQ_scope table 849 

A record in this table looks like this: 

AQ_scope ( 

id NUMBER (12) NOT NULL, 

name VARCHAR2 (254 ) NOT NULL, 

25 projects_ids TEXT NOT NULL, 

date_updated DATE NOT NULL, 
primary key (id) 

) 

30 A record in AQ_scope table 849 specifies a scope for an administrative query, 

that is, it defines a subset of the records in PR 833 over which the query is to run. In the 
preferred embodiment, the subset is defined by specifying selected projects defined in 
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Project table 831. The subset is made up of all of the records in PR table 883 whose 
projected fields specify records in Project table 831 for the selected projects. 

This table contains the following data fields: (a) id: unique Scope ID, (b) 
name: given Scope name, (c) project_ids: a list of the names of all projects to be 
5 included (thus, filtering out other projects); the names are values of name fields 
in records in Project table 831; and (d) date_updated: the date and time that this 
record was last updated. 

AQ_schedule table 851 and AQ_schedule_detail table 852 

10 These tables contain information that system 801 uses to schedule the next 

execution of an administrative query. Beginning with AQ_schedule table 851, a 
record in the table has the following fields: 

AQ schedule ( 

id NUMBER (12) NOT NULL, 

1 5 name VARCHAR2 (254) NOT NULL , 

date_updated DATE NOT NULL, 
primary key (id) 

) 

20 A record in AQ_schedule table 851 specifies a schedule for executing an 

administrative query. This table contains the following data fields: (a) id: unique 
Schedule ID, (b) name: given Schedule name, and (d) date_updated: the date and 
time that this record was last updated. The value of the unique identifier for the 
record is used to locate a record in the AQ_schedule_detail table that contains the 

25 actual information used to schedule the query. 
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AQ_schedule_detail ( 



10 



id 

aq_schedule_.id 

day_in_week 

day_in_month 

start_time 

end_time 

t ime_i nt e r va 1 

date_updated 

primary key (id) 



NUMBER (12) 
NUMBER (12) 
NUMBER (4) , 
NUMBER (4) , 
NUMBER (6) , 
NUMBER (6) , 
NUMBER (12 ,2) , 
DATE NOT NULL, 



NOT NULL, 
NOT NULL, 



A record in AQ_schedule_detail table 852 specifies the Schedule details 
15 for the AQ schedule represented by the record in AQ schedule table 851 referred 
to by the value in the aq_schedule_id field. The schedule detail determines when 
an administrative query that specifies the schedule will be executed. This table 
contains the following data fields: (a) id: unique ID in this table, (b) 
aq_schedule_id: the ID of the record in AQ_schedule table 851 for the schedule 
20 that is using this Schedule Detail, (c) day_in_week: day in the week that the 
query is to be executed, e.g., 1 = Sunday, 2 = Monday, etc. (d) day_in_month: day 
in the month to be executed, e.g., 1 = the first day in the month, 2 = the second 
day in the month, etc., (e) start_time: the first time to execute the AQ during the 
given day, (f) end_time: the last time to execute the Query in the given day, (g) 
25 the time interval, specified in minutes, between consecutive Query executions, 
and (h) date_updated: the date and time that this record was last updated. 

When an administrative query that uses the AQ schedule detail record is 
executed, the information in the AQ_schedule_detail record is used to update the 
administrative query's record in current schedule table 823 to specify the next 
30 execution of the query. Where a time interval is specified, it is added to the time 
specified for the last execution of the query in the administrative query's record 
in current schedule table 823. The administrative query thus effectively 
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schedules its next execution itself. One advantage of this arrangement is that the 
form of a record in current schedule table 823 is independent of the kind of 
scheduling being done; further, the table itself need have only one record for a 
given administrative query, regardless of the frequency with which the given 
5 administrative query is being executed or the complexity of its execution 
schedule. 



Program_sequence table 855 

Program_sequence table 855 specifies additional activities that can be 
10 performed for a process whose record in PR 833 has been retrieved by an 
execution of an administrative query with regard to which the retrieved PR 
record is in the state of Persistent Conditions. A record in Program_sequence 
table 855 looks like this: 



Program sequence ( 

15 id NUMBER (12) NOT NULL, 

admin_query_id NUMBER (12) NOT NULL, 

sequence_number NUMBER (6) NOT NULL, 

time_interval NUMBER ( 12 , 2 ) , 

pr_activity_type NUMBER (12) , 
20 program_control NUMBER (6) NOT NULL, 

date_updated DATE NOT NULL, 

primary key (id) 

) 

25 There may be a number of records in Program_sequence table 855 for a 

given administrative query. The set of records for the given administrative 
query is called the administrative query's program sequence. The program 
sequence associated with a given administrative query specifies administrative 
activities that are to be executed with regard to a PR record that is in a state of 

30 Persistent Conditions with regard to the current execution of the administrative 
query. The set of records specifies not only the administrative activities, but also 
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the order in which they are performed by executions of the administrative query 
for which the PR record is in the state of Persistent Conditions, and the temporal 
conditions under which they are to be executed. The parts of a program 
sequence record that specify these things are termed instruction elements, and 
5 taken together, the instruction elements in a program sequence record define an 
instruction. In the preferred embodiment, each record in Program_sequence table 
855 specifies a set of three instruction elements: a Type instruction element, an 
Admin Activity Type instruction element, and an Elapsed Time instruction 
element. The Type instruction element specifies the Program sequence record 

10 that will be used the next time the query with which the program sequence 
record is associated is executed; the Admin Activity Type instruction element 
specifies the Administrative activity type of the activity to be performed and is 
thus a pr_activity_type field 609 referencing Admin_activity_type subtable 841; 
the Elapsed Time instruction element specifies a minimum time from the time 

15 the last administrative activity was executed by the query for a given PR record 
to the time the administrative activity specified by this Program_sequence record 
is to be executed. Other embodiments may have different instruction elements 
and more or fewer of them. 

20 A record in Program_sequence table 855 contains the following data 

fields: (a) id: unique Program Sequence record ID, (b) admin_query_id: the id of 
the record in Admin_query 853 for the query that this record is associated with, 
(c) sequence_number: the sequence number for the record in the program 
sequence for the administrative query specified by the value of admin_query_id; 

25 (d) time_interval: the Elapsed Time instruction element, (e) pr_activity_type: the 
Admin activity type of the activity to be performed; this field is the Admin 
Activity Type instruction element; (f) program_control: the Type Instruction 
Element; this field may have values from the group of: (fl) Stop, (f2) Next, or (f3) 
Continue, where Stop means ceasing to execute any further administrative 
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activities for a given PR record while the given PR record is in the state of 
Persistent Conditions with regard to an execution of the Admin Query, Next 
means using the next program sequence record in the query's program sequence 
the next time the query is executed, returns the given PR record, and the given 
5 PR record is in the state of Persistent Conditions with regard to the execution, 
and Continue means again executing the present program sequence record the 
next time the query is executed returns the given PR record, and the given PR 
record is in the state of Persistent Conditions with regard to the execution, and 
(g) date_updated: the date and time that this record was last updated. It should 
10 be noted that in other embodiments, the Type instruction element may be able to 
specify any program sequence record in the query's program sequence, i.e., the 
Type instruction element may function as a "goto" or include a conditional 
branch. 

The Elapsed Time Instruction element specifies the minimum elapsed 
15 time from the previous time that an administrative activity was performed for a 
given administrative query and a given PR record to the time when the 
administrative activity specified in the current record in the Program_sequence 
table 855 should next be executed. More specifically, if a PR record is in the state 
of Persistent Conditions when the given administrative query is executed again, 
20 but the time elapsed from the last action taken to the current time is less than the 
specified Elapsed Time, then the administrative activity specified in the current 
program sequence record will not be performed and the current value of the 
Next Sequence Pointer will remain unchanged. As a result, the same record in 
the Program Sequence Table will be considered again if the state of Persistent 
25 Conditions still exists for the given PR record on the next execution of the given 
AQ that returns the given PR record. 
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Example of a program sequence and its execution 

An example of a program sequence associated with an administrative 
query "All Past Due Items" that returns PR records 833 with items that have 
passed their deadlines without action being taken is the following: 

5 Program sequence record for the "All Past Due Items" query with 

sequence_number = 1: 

Type = "Next"; 

Elapsed Time = 30 minutes; and 

Administrative activity type to be Executed = "Send email 
1 0 notification and escalate priority" 

Program sequence record for the "All Past Due Items" query with 
sequence_number = 2: 

Type = "Continue"; 

Elapsed Time = 24 hours; and 

1 5 Administrative activity type to be Executed = "Notify 

management" 

According to this example, if the AQ "All Past Due Items" is scheduled for 
execution every day and once every hour of the day, and if PR record #1012 was 
first included in the Result Set (the set of records returned by the query) at 10:00 

20 AM on a given day, then the Initial administrative activity specified in the query 
will be executed with regard to PR record #1012 and a Next Sequence Pointer in 
the record for the query and PR record in AQ_PR_log 875 will be set to the 
numeric value of one. Thereafter, if this PR is in the state of Persistent 
Conditions (as determined from records for the query and PR record in 

25 Admin_queryJog 873 and AQ_PR_log 875) at 11:00 AM, system 801 will retrieve 
the record in the query's program sequence in which sequence_number=l, and 
since the specified Elapsed Time is 30 minutes and the actual elapsed time from 
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the previous execution is one hour, the condition of the Elapsed Time will have 
been satisfied and system 801 will execute the Administrative activity type 
specified by the value of the record's pr_activity_type and will increment the 
Next Sequence Pointer by one, so that it points to the second program sequence 
5 record in the program sequence. 

When system 801 next executes the administrative query associated with 
the program sequence at 12:00 PM, if PR #1012 is still part of the result set and 
PR #1012 is in the state of Persistent Conditions, system 801 will follow Next 
Sequence Pointer to the second record in the program sequence for the 

10 administrative query. However, since the Elapsed Time specified for this 
sequence record is 24 hours, and since the actual elapsed time from the previous 
execution is only one hour, the condition of Elapsed Time of 24 hours will not be 
satisfied and therefore the administrative activity for this sequence record will 
not be performed. Since the administrative activity was not performed, the Next 

15 Sequence Pointer will not be incremented. The specified administrative action 
will only be performed if PR #1012 continues to be in the state of Persistent 
Conditions throughout the next 23 hours, and it will not be until system 801 
executes the "All Past Due Items" AQ the next day at 11:00 AM that the "Elapsed 
Time" Instruction Element of 24 hours will be satisfied, at which time system 801 

20 will perform the administrative action of the type "Notify Management" 
specified for the second record in the program sequence. Having performed the 
administrative action, system 801 will perform the operation specified by Type 
on the Next Sequence Pointer. Type specifies "Continue", and consequently, 
system 801 will not change the value of the Next Sequence Pointer. Therefore, as 

25 long as PR #1012 stays "Past Due", management will continue to be notified 
every day at 11:00 AM that PR #1012 is in such a state. The above example 
shows how detection of the state of Persistent Conditions and an administrative 
query's program sequence can be used to enable system 801 to check the status of 
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a process with a high degree of frequency without generating notifications on 
every status check. 

It should be pointed out here that, seen in general terms, an 
administrative query's program sequence defines a set of behaviors that 

5 correspond to a set of substates that a PR record may be in when the PR record is 
in the state of Persistent Conditions with regard to an execution of an 
administrative query. In the preferred embodiment, information about what 
substate a given PR record is presently in is preserved between executions of the 
query in the Next Sequence Pointer in the record for the query and the given PR 

10 record in AQ_PR_log 875 In other embodiments, the substate information may 
be preserved between executions of the query in other forms. 

Details of log tables 871 

Admin_query_log table 873 and AQ_PR_log 875 together contain the 
15 information that system 801 uses to determine when to perform the next 
administrative activity for a PR record returned by an execution of a given 
administrative query and what administrative activity the next administrative 
activity should be. 



20 Admin _query Jog 873 

A record in this table looks like this: 



Adminquerylog ( 

id 

aq_scope_id 
25 admin_query__id 

pr_query__id 

host_name 

datetime_executed 

pr_count_matched 
30 pr_count_executed 

date_updated 



NUMBER (12) NOT NULL, 
NUMBER (12 ) , 
NUMBER (12) NOT NULL, 
NUMBER (12) NOT NULL, 
VARCHAR2 (254) , 
DATE NOT NULL, 
NUMBER (12) , 
NUMBER (12) , 
DATE NOT NULL 
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Admin_query_log table 873 logs the execution of every administrative 
query by system 801. There is a record for every execution of each of the 
administrative queries. Records in the table contain the following data fields: (a) 
id: unique AQ Log ID, (b) aq_scope_id: the ID of the record in AQ_scope table 
5 849 for the scope of the execution of the administrative query represented by the 
record; (c) admin_queryjd: the ID of the record in Admin_query table 853 for 
the administrative query whose execution is represented by the 
Admin_query_log record; (d) pr_query_id: the ID of the record in PR_query 847 
that defines the query used in the execution represented by the record; (e) 

10 host_name: which server this AQ executed on in the execution represented by 
the record, (f) datetime_executed: the date and time of the execution represented 
by the record; this field is set after system 801 has performed any necessary 
administrative actions on all of the PR records in the result set returned by the 
administrative query; this value is further one of the values used to determine 

15 whether Persistent Conditions exist with regard to the current execution of the 
administrative query and a particular PR record returned by the execution; (g) 
pr_count_matched: the count of PRs that matched given Query (set of 
conditions) in the execution represented by the record; (h) pr_count_executed: 
the count of PRs for which an administrative action was performed during the 

20 execution represented by the record, and (i) date_updated: the date and time 
that this record was last updated. 

AQ^PRJog table 875 

25 This table has a record corresponding to each PR record returned by a 

given execution of an administrative query. This record further contains the 
Next Sequence Pointer that determines which Administrative activity type will 
next be executed by system 801 for the given query and PR record. 
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AQJPRJog ( 

id NUMBER (12) NOT NULL, 

admin_query_id NUMBER (12) NOT NULL, 
pr_id NUMBER (12) NOT NULL, 

5 date_aq_executed DATE, 

date_aa_executed DATE, 

pr_activity_type NUMBER (12) NOT NULL, 
next_sequence NUMBER (6) , 
date_updated DATE NOT NULL 

10 ) 



AQ PR log table 875 logs PR records that were returned when a given 
administrative query was executed. Each record represents a particular PR 
record-administrative query execution pair. A record contains the following data 

15 fields: (a) id: unique id of the record in the table, (b) admin_query_id: the ID of 
the particular administrative query that was executed, (c) pr_id: an identifier for 
the PR record that was returned when the given administrative query was 
executed; (d) date_aq_executed: the date and time of the particular execution of 
the administrative query; this value is equal to the value of the 

20 datetime_executed field in the Admin_queryJog table record for the same 
particular execution of the administrative query; (e) date_aa_executed: the date 
and time that the last administrative action was performed for the administrative 
query and PR record; (f) pr_activity_type: the Administrative activity type for the 
most recently performed administrative activity; (g) next_sequence: the value of 

25 the Next Sequence Pointer, and (h) date_updated: the date and time that this 
record was last updated. 

Using AQJPRJog table 875 and Admin_queryJog 873 to determine whether a process 
represented by a PR record is in a state of Persistent Conditions or a state of First 
Occurrence 

30 A given PR record is in a state of Persistent Conditions with regard to an 

execution of a given administrative query that returns the given PR record if the 
immediately preceding execution of the given administrative query also returned 
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the given PR record. This of course means that the process condition which the 
given administrative query is intended to monitor is persisting with regard to the 
given PR record. If the given PR record is not in a state of Persistent Conditions, 
it is in a state of First Occurrence. 

When system 801 executes the given administrative query, the execution 
returns the given PR record, and the given PR record is in a state of First 
Occurrence with regard to the execution, system 801 performs the initial 
administrative action specified for the given administrative query. When the 
given PR record is in a state of Persistent Conditions with regard to the 
execution, system 801 performs the administrative action specified in the 
Program_sequence table record for the given administrative query that is 
pointed to by the current value of the Next Sequence Pointer. 

A preferred embodiment of system 801 detects the existence of a state of 
Persistent Conditions or a state of First Occurrence for a given execution of an 
administrative query and a given PR record returned by that execution from the 
information about executions of the given administrative query that is contained 
in Admin_query Jog table 873 and the information about executions of the given 
administrative query and the PR records they returned that is contained in 
ACLPRJog table 875. The state of Persistent Conditions is detected as follows: 
when system 801 is executing a given administrative query and the 
administrative query returns a result set that includes a given PR record, system 
801 searches in AQ_PR log record for a record that matches the given PR record 
and given administrative query. If such a record is found, system 801 compares 
the value of the date_aq_executed field in the AQ_PR log record with the value 
of the datetime_executed field of the most recent Admin_query_log record for 
the given administrative query. There are three possible outcomes: 

1. There may be no AQ_PRJog record at all for the given PR record and 
the given administrative query; if that is the case, this is the first time 
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the given PR record has been part of the result set returned by the 
given administrative query and the given PR record is in a state of 
First Occurrence for this execution of the given administrative query. 

2. There is an AQ_PR_log record for the given PR record and the given 
5 administrative query, but the value in the date_aq_executed field is 

less recent than the value in the datetime_executed field in the most 
recent Admin_query_log record for the given query, indicating that 
the immediately preceding execution of the given query did not 
return the given PR record in its result set and that the given PR 
10 record is therefore not in the state of Persistent Conditions; thus the 

given PR record will again be in the state of First Occurrence for this 
execution of the given administrative query. 

3. There is an AQ__PR_log record for the given PR record and the given 
administrative query, and the value in the date_aq_executed field is 

15 equal to the value in the datetime_executed field in the most recent 

Admin_query_log record for the given query, indicating that the 
immediately preceding execution of the given query did return the 
given PR record in its result set; thus the given PR record is in the state 
of Persistent Conditions for this execution of the given administrative 

20 query. 

A scenario that will produce outcome (2) above is the following: an 
administrative query called "Find overdue PR records" returns all PR records 
where the value of the is_closed field is zero, indicating that the record is still 
open, and the value in the date_due field is less recent than the time of the 
25 current execution of the administrative query. The administrative query is run 
every hour. PR record #120, has a date_due field that specifies 11:30. When the 
administrative query is run at 12:00, it returns PR record #120. Then, at 12:30, the 
person responsible for the process extends the deadline by setting the date_due 
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field in record #120 to 1:30. When the administrative query is run at 1:00, it does 
not return PR record #120. The 1:30 deadline is also not met, and when the 
administrative query is run at 2:00, it again returns PR record #120; however, 
since the administrative query returned PR record #120 at 2:00 but did not return 
5 it at 1:00, PR record #120 is not in the state of Persistent Conditions with regard 
to the "Find overdue PR records" administrative query at 2:00, but is instead 
again in the state of First Occurrence. 

AQjrends table 879 

10 As shown in Fig. 8, this table properly belongs to administrative queries 

tables 845. AQjrends table 879 logs information which system 801 can use to 
determine trends in the way in which the processes being monitored by a given 
administrative query are behaving and to perform administrative actions as 
determined by those trends. 

15 

There may be a record in this table for every administrative query for 
which trends are being tracked. The record for a given administrative query can 
be configured to recognize trends over a particular time interval in the number of 
PR records returned by executions of the given administration query and to 

20 specify administrative activities for particular trends. When a particular 
threshold is reached and detected during an execution of the administrative 
query, the execution of the administrative query may result in the performance 
of an administrative action on a particular PR record that is separate from the PR 
records returned by the administrative query. The interaction between the 

25 record for an administrative query in the AQ_trends table and executions of the 
administrative query is another example of conditional performance of an 
administrative action based on a condition that is detected during execution of 
the query. 
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One administrative activity specified in the AQ_trends table record may 
set a field in the separate PR record indicating that the threshold for a trend in 
one direction has been exceeded, and another may reset that field if a trend is 
below the given threshold. The determination of "exceeding" the threshold or 
5 going "below" a given threshold is dependent on a direction qualifier. Another 
administrative query may query PR records set by these administrative activities 
and when one of these records is in a state of Persistent Conditions over time, 
indicating that a trend is continuing, an execution of the other administrative 
query may result in performance of an administrative activity that notifies 
10 someone or takes some other action to remedy the trend. 

A record in AQjrends table 879 has the form: 
AQ trends ( 

id NUMBER (12) NOT NULL, 

admin_query_id NUMBER (12) NOT NULL, 
15 time_interval NUMBER (12, 2) NOT NULL, 

direct ion_type NUMBER (2) NOT NULL, 

percentage_set NUMBER (12,4) , 

percentage_reset NUMBER (12, 4) , 

pr_id NUMBER (12) NOT NULL, 

20 aa_post_on_set NUMBER ( 12 ) , 

aa_post_on_reset NUMBER (12) , 

date_updated DATE NOT NULL 

) 

A record in AQ_trends table 879 can be configured to respond to trends 
25 visible in the executions of the administrative query associated with the record, 
based on the number of PR records that match given administrative query, as 
reflected in the values of the 'pr_count_matched' field in the query's 
Admin_queryJog table 873, and the behavior of the values of that field over 
time. This table contains the following data fields: (a) id: unique ID in this table, 
30 (b) admin_query_id: the ID of the specific administrative query, which the given 
record is configured for, (c) timejnterval: a specific time interval, across which a 
trend is calculated, e.g., 24 hours, (d) direction_type: an indicator for whether a 
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watch is on an increase in 'pr_count_matched', or a decrease in same, (e) 
percentage_set: is a threshold, which when exceeded, will cause system 801 to 
perform a "set" administrative activity during execution of the administrative 
query on a PR record; (f) percentage_reset: is a threshold, below which the same 
5 is done with a "reset" administrative activity; (g) pr_id: a unique identifier for the 
PR record which will be operated on by the set and reset administrative 
activities, (h) aa_post_on_set: an identifier for the record in Admin_activity_type 
table 841 for the set administrative activity's administrative activity type; (i) 
aa_post_on_reset: the same for the reset administrative activity, and (j) 
10 date_updated: the date and time that this record was last updated. 

Details of action tables 857 

The actions performed by system 801 when it executes a given Administrative 
activity type are described in records in action tables 857 whose pr_activity_type 

15 fields contain the unique identifier of the given Administrative activity type's 
record in PR_activity type table 837. There are a number of kinds of actions, and 
each kind has its own table in action tables 857. If an Administrative activity 
type is seen as a kind of program, the actions associated with a given 
Administrative activity type can be seen as the Administrative activity type's 

20 instructions. As with normal program instructions, the action performed by a 
given program instruction may depend on a value that is obtained at runtime. 
When the actions belonging to a given administrative activity are executed, they 
are executed in the order given by the values of the action records' identifiers. In 
other embodiments, there may be other provisions for establishing an order in 

25 which the actions are executed and there also may be provisions for gotos and 
conditional branches. An important aspect of the present invention is the ability 
to easily modify pre-existing Administrative activity types. To modify an 
administrative activity type, one needs only modify the records in action tables 
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857 for the actions belonging to the administrative activity type, either by adding 
or deleting records or editing existing records. Modification of an administrative 
activity is not only easy, but safe, since the modifications are constrained by the 
fields available in the action records being added, deleted, or edited. 

5 In a preferred embodiment, there are three broad classes of actions: those 

which modify a PR record which belongs to the result set returned by an 
administrative query; those which post records for activities to the PR_activity 
table, and one action which generates a report about the PR records in the result 
set returned by the administrative query. The relationship between these classes 
1 0 of actions and the kinds of actions are as follows: 

• Kinds of actions which modify PR records: 

- AA_set_values actions in table 859: these actions set or increment 
fields in PR records that contain neither person nor date values. 

- AA_set_person actions in table 863: these actions set fields in PR 
1 5 records that contain person values. A person value is an identifier 

for a person known to system 801. 

- AA_set_dates actions in table 861: these actions set fields in PR 
records that contain date values. The date fields are set with 
reference to other date fields in the PR records or with reference to 

20 the date and time when an administrative activity is performed. 

• Kinds of actions which post records in PR_activity table 839: 

- AA_post_activities actions in table 865: these actions post records 
for any kind of activity type in PR_activity table 839. The posting 
may either schedule an activity for performance or indicate that the 

25 activity has been performed. 

-. PR_notification actions in table 865: these actions generate and 
send a notification to a list of people that is associated with the 
process's PR record, post a record to PR_activity table 839 for the 
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notification, and makes a record in another table (not shown) which 
indicates who received notifications. 

• Report generating actions: 

- AA_exec_report actions in table 865: generates a report which 
5 includes all the PR records of the result set returned by the 

administrative query that is performing the administrative activity 
that contains the action, formats the report based on a specified 
report template, converts its to a PDF file, and mails out the PDF 
file as an attachment to recipients based on a configurable recipient 
10 list. 

An action table record associated with a given Administrative type may come 
from any of the action tables and an Administrative type may have any number 
of action table records associated with it. To clarify by example, for a given 

15 Administrative activity type, system 801 can be configured to have no records in 
AA_set_values actions table 859, which means that upon performing this given 
Administrative activity type, there will be no effect on any non-date or any non- 
person field values in the matching PR records; one record in the AA_set_person 
actions table 863, indicating one specific person field to be affected; and three 

20 records in AA_set_dates actions table 861, indicating three specific date or date- 
time fields to be affected by this given Administrative activity type. The same is 
true for the other kinds of actions. 

It should be pointed out here that in general, the kinds of actions defined 
25 for an embodiment of the invention will depend on the kind of process being 
controlled by the invention. The kinds of actions in the preferred embodiment 
are typical for embodiments that are intended to control business and 
administrative processes. Embodiments that are intended to control industrial or 
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technical processes may have actions that result in physical actions being 
performed. Examples might be sounding an alarm, adjusting a valve, or 
rerouting a stream of packets. The details of the action tables are presented in 
the order of the above taxonomy. 

5 

AA_set_values table 859 

The actions represented by the records in this table affect values in PR 
records returned by the administrative query that performs an administrative 
activity which includes the record's action. 

10 Records in this table have the following form: 

AA set values ( 

id NUMBER (12) NOT NULL, 

pr_activity_type NUMBER (12) NOT NULL, 
data_field_id NUMBER (12) NOT NULL, 

15 action_type NUMBER (6) NOT NULL, 

set_type_id NUMBER (12) NOT NULL, 

date_updated DATE NOT NULL 

) 

20 Records in AA_set_values table 859 contain the following data fields: (a) id: 

unique ID of the record in this table, (b) practivitytype: the ID of a record in table 837 
for a specific administrative activity type to which the action belongs; (c) data_field_id: a 
value that specifies what field is to be affected by the action in the PR records of the 
result set returned by the query execution that is performing the administrative activity. 

25 There is a value of data_field_id associated with each of the fields that is defined for a PR 
record, (d) actionjype: action to be taken: incrementing the current value of the field 
specified by the value of data_field_id, or setting that field to a pre-determined value, (e) 
set_type_id: a value to be used in setting the specified field; when action_type specifies 
increment, the value of set type id is the value by which the value in the field specified 

30 by data_field_id is to be incremented (or decremented); otherwise, it is a constant value 
to which the field is to be set, and (f) date_updated: the date and time that this record was 
last updated. 
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AA_set_person table 863 

The actions represented by the records in this table affect person values in 
PR records returned by the administrative query that performs an administrative 
activity which includes the record's action. 

5 Records in this table have the following form: 

AA_set_person ( 

id NUMBER (12) NOT NULL, 

pr_activity_type NUMBER (12) NOT NULL, 
data_field_id NUMBER (12) NOT NULL, 

10 person_role_type NUMBER (12) NOT NULL, 

person_rel_id NUMBER (12) NOT NULL, 

date_updated DATE NOT NULL 

) 

Records in this table contain the following data fields: (a) id: unique ID of 
15 the record in this table, (b) pr_activityjype: the ID of the record in 
PR_activity_type table 837 of the Administrative activity type to which this 
action belongs; (c) data_field_id: an identifier for the field in the PR record that is 
to be affected by the action, (d) person_rel_id: if not null, the value to be assigned 
to the field specified by data_field_id; this value is an identifier for a specific 
20 person, (e) person_role_type: if not null, a value for a role that is to be assigned to 
the affected field; in this case, system 801 will select an ID of a person from a 
circular list of persons with the given role. System 801 remembers the last person 
selected from the list in conjunction with performance of an activity of the given 
Administrative activity type, so that on the next occurrence of such an activity, 
25 system 801 will select the next person on the given list; and (f) date_updated: the 
date and time that this record was last updated. 
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AA_set_dates table 861 



The actions represented by the records in this table affect date or date and 
time values in PR records returned by the administrative query that performs an 
administrative activity which includes the record's action. 

Records in this table have the following form: 



AA set dates ( 

id 



10 



15 



pr_act ivi ty_type 
data_f ield_id 
da t a_f i e 1 d__no t_s e t 
no t _s e t _add_va lue 
data__f ield_if_set 
s e t __add_va 1 ue 
business_days_rule 
date_updated 



NUMBER (12) 
NUMBER (12) 
NUMBER (12) 
NUMBER (12) , 
NUMBER (12) , 
NUMBER (12) , 
NUMBER (12) , 
NUMBER (2) , 
DATE NOT NULL 



NOT NULL, 
NOT NULL, 
NOT NULL, 
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Records in this table contain the following data fields: (a) id: unique ID in this 
table, (b) pr_activity_type: the ID of the record in PR_activity_type table 837 that 
represents the administrative activity type that the action represented by the 
record belongs to; (c) data_fidd_id: an identifier for a date or date/ time field in 

5 the PR record which is to be affected by the change, hereinafter the "affected 
field"; (d) data_field_not_set: an identifier for a field in the PR record whose 
value specifies a date or date/ time type field; the field's value is used as a 
reference value when the current value of the affected field is null, (e) 
not_set_add_value: a numeric value to be added to the reference value of the 

10 when the affected field is null; the affected field is set to the result of the addition; 
(f) data_field_if_set: an identifier for a field in the PR record whose value 
specifies a date or date/ time type field; the field's value is used as a reference 
value when the current value of the affected field is not null, (e) set_add_value: a 
numeric value to be added to the reference value when the affected field is non- 

15 null; the affected field is set to the result of the addition; (h) business_days_rule: 
a code specifying whether the value of the not_set_add_value or the 
set_add_value field represents business days or calendar days; and (i) 
date_updated: the date and time that this record was last updated. Note 1: 
'not_set_add_value' and 'set_add_value' may be positive, negative, or zero and 

20 may also specify fractions of days. Note 2: if a reference field id equals a given 
constant, e.g., -1, this indicates to system 801 to not use any specific date or 
date/ time field, but rather, the date/ time of when the given administrative 
activity is executed, i.e., the then current time. 

25 AA_post_activities table 865 

Records in AA_post_activities table 865 represent actions that post records 
in PR_activity table 839 for non-administrative activities. The action may post 
the activity as either having been performed or scheduled to be performed. 
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Records in this table have the following form: 

AA_post_activities ( 

Id NUMBER (12) NOT NULL, 

pr_activity_type NUMBER (12) NOT NULL, 
5 post_activity_type NUMBER (12) NOT NULL, 

posting_mode NUMBER (2) NOT NULL, 

data_f ield_date NUMBER (12) , 
add_value NUMBER ( 12 ) , 

business_days_rule NUMBER (2 ) , 
10 data_field_person NUMBER ( 12 ) , 

responsible_rel_id NUMBER (12) , 
date_updated DATE NOT NULL 

) 

15 Records in AA_post_activities contain the following data fields: (a) id: unique ID of the 
record in this table, (b) pr_activity_type: the ED of the record in PR_activity_type table 
837 that represents the administrative activity type that the action represented by the 
record belongs to; (c) post_activity_type: the ID of the record in PR_activity_type table 
837 that represents the activity type of the non-administrative activity being posted in 

20 PR activity table 839; (d) posting_mode: a code specifying whether the non- 
administrative activity should be posted as a scheduled activity or as a performed activity, 
(e) data_field_date: an identifier for a field in the PR record whose value specifies a date 
or date/time type field; the field's value is used as a reference value to compute a date or 
date/time at which the non-administrative activity is to be scheduled for performance if 

25 the value of posting_mode indicates that the non- administrative activity should be 
scheduled, rather than performed right away; (f) add value: a numeric value to be added 
to the reference value in the case where posting_mode indicates that the given activity 
should be posted as scheduled; the result of this addition will be used to set the 
date_scheduled field of the given PR Activity record; (g) business_days_rule: a code 

30 specifying whether the value of the add_value field represents business days or calendar 
days; (h) data_field_person: an identifier of a person type data field in the PR record the 
administrative activity is being performed on whose value is to be used to indicate the 
person responsible in the PR_activity record being posted; (i) responsible_rel_id: the 
value of this field is an identifier for a person who is the person responsible for the given 

35 PR Activity; the value will be used in the responsible_rel_id field of the PR_activity 
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record being posted; (j) date_updated: the date and time that this record was last updated. 
Note 1: the value of 'addjvalue 5 is specified using any desired day or fraction of a day 
units. Note 2: the specifiers 'data_field_person' and 'responsible_rel_id' are mutually 
exclusive. Note 3: When posting a PR_activity record as a performed activity, system 
5 801 sets the date_performed field of the PR_activity record to the date/time that said 
activity was posted by the system, yet leaves the date scheduled field null, whereas when 
posting an activity as a scheduled activity, system 801 sets the date scheduled field of the 
activity as explained above, yet leaves the date performed field null. 



PR_notification table 867 

The actions represented in the records of this table generate a record in 
PR_activity_type table 837 for a notification activity that sends a notification to a 
list of people that are associated with the process's PR record, posts a record to 
PR_activity table 839 for the notification activity, and makes a record in another 
table that keeps track of who received notifications. 

Records in table 867 have the following form: 

PRnotification ( 

id 

project_id 
20 pr_activity_type 
trigger_type 
pr__owner 
customer 
originator 
25 report ing_to 

activity_members 
date_updated 
primary key (id) 

) 

30 

Records in this table contain the following data fields: (a) id: a unique ID 
in this table, (b) projected: a specific Project ID, as notifications may be 
configured differently in different projects, (c) pr_activity_type: the ID of the 
record in PR_activity_type table 837 that represents the administrative activity 



10 



15 



NUMBER (12) NOT NULL, 
NUMBER (12) NOT NULL, 
NUMBER (6) NOT NULL, 
NUMBER (6) NOT NULL, 
NUMBER (1) NOT NULL, 
NUMBER (1) NOT NULL, 
NUMBER (1) NOT NULL, 
NUMBER (1) NOT NULL, 
NUMBER (1) NOT NULL, 
DATE NOT NULL, 
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type that the action represented by the record belongs to; (d) trigger_type: an 
indicator of when notification should be triggered, e.g., when the notification 
activity is posted as a scheduled activity to the PR_activity table 839 or when it is 
actually performed; (e) pr_owner: if the value equals one, the PR owner, i.e., the 
5 Assigned To person, should be notified, (f) customer: if the value equals one, the 
PR main contact should be notified, (g) originator: if the value equals one, the PR 
originator, e.g., the requestor, should be notified; (h) reporting_to: if the value 
equals one, the manager of the Assigned To person should be notified, (i) 
activity_members: if the value equals one, all members of the given activity 
10 should be notified; all of these persons are identified in a record associated with 
the PR record for which the activity is executed; and (j) date_updated: the date 
and time that this record was last updated. 

AA_exec_report table 869 

15 The actions represented by the records in this table generates a report 

concerning the PR records of the result set returned by the query which performs 
the activity to which the action belongs. 

Records in table 869 have the following form: 

AAexecreport ( 

20 id NUMBER (12) NOT NULL, 

pr_activity_type NUMBER (12) NOT NULL, 
report_template_id NUMBER (12) NOT NULL, 
f ilename_path VARCHAR2 (254) , 

date_updated DATE NOT NULL 

25 ) 

The records in AA_exec_report table 869 represent actions that generate reports. 
A report is generated using a configured report template and includes all the PR 
records that were matched by the administrative query that resulted in the 
30 performance of the activity the action belongs to. The AA_exec_report table 869 
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contains the following data fields: (a) id: unique ID in this table, (b) 
pr_activity_type: the ID of the record in PR_activity_type table 837 that 
represents the administrative activity type that the action represented by the 
record belongs to; (c) report_template_id: the id of a template for the report to be 
5 generated by the action; (d) filename_path: a complete filename and path 
specifying where the report should be saved - this is not a mandatory field, and 
if not specified, the report will be generated as a temporary file - either the 
specified file or the temporary file is then sent electronically as an attachment to a 
specified list of recipients; and (e) date_updated: the date and time that this 
10 record was last updated. The list of recipients is in another table; the record for 
each recipient has a pr_activity_type value that specifies the record for the 
administrative activity type that the action represented by the AA_exec_report 
record belongs to. 

15 Details of the operation of system 801: FIGs. 1-4 

Overview of operation: FIG. 1. 

FIG. 1 is a high-level flowchart 101 of the operation of system 801. The 
first step (103) is configuring the system. The configuration process begins after 

20 a process that is to be monitored by system 801 has been designed. First, the 
persons doing the configuration design a PR record for the process, with the 
particular fields required to monitor the process. Once this is done, the persons 
doing the configuration can configure the administrative queries that will do the 
actual monitoring. The administrative queries are configured by making or 

25 selecting records in administrative query tables 845 for the entire query (in 
Admin_query 853), for the SQL for the query (in PR_query 847), for the scope of 
the query (in AQ_scope 849), for the schedule for executing the query (in 
AQ_schedule_detail 852), and for the administrative activities to be executed by 
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the query (in PR_activity_type 837). The actions for each administrative activity 
must further be defined in records in action tables 857. The PR_activity_type 
record for the initial administrative action for the query is specified in the query's 
record in Admin_query 853; this activity is performed whenever a PR record 
5 returned by the query is in the state of First Occurrence. PR_activity_type 
records for the activities that are performed when a PR record returned by the 
query is in the state of Persistent Conditions are specified in a program sequence 
for the query of Program_sequence records in table 855. It is an important 
advantage of system 801 that a query may be configured using records in 
10 PR_query table 847, AQ_scope table 849, AQ_schedule table 851, and 
Admin_activity_type table 841 that were created for other queries. This feature 
permits work that was previously done to configure another query to be reused 
in configuring a new query. 

Once the process has been designed and records in the tables in DB 
15 system 825 have been properly configured, system 801 can begin executing 
administrative queries for the process. System 801 loads all the configuration 
information from administrative query tables 845, and Action tables 857 to 
construct current schedule table 823 and current query and processing plans 
table 824 in memory 809 of computer 803 in system 801; then selects the next 
20 administrative query to be executed from the current schedule table 823. Each 
time an administrative query is executed, system 801 uses the information for 
scheduling stored in current schedule table 823 for the query to specify the time 
of the query's next execution; each time this is done, system 801 finds the record 
in schedule table 823 that has the shortest time remaining until execution and 
25 executes the query when that time has expired, as shown in step 105. 

If there is no query to be executed at the present time, system 801 takes 
branch 109 and checks whether any changes have been made in the 
configuration tables that define the processes and queries in DB system 825, 
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namely: administrative query tables 845 and Action tables 857 (step 115); if there 
are no changes in the configuration, branch 107 is taken back to decision block 
105; if there are any changes, branch 117 is taken and the updated configuration 
from the configuration tables in DB system 825 is fetched and the current 
5 schedule table 823 and the current query and processing plans table 824 are 
modified as required for such changes (step 119), and when that is done, system 
801 returns to decision block 105 and again checks whether it is time to execute 
the next scheduled administrative query (loop 121). 

If there is a query to be executed, system 801 executes the administrative 

10 query as it has been configured in tables 845 (block 113), as reflected in the 
current query and processing plans table 824: the query specified in the 
administrative query's PR_query record is executed on the PR records belonging 
to the scope specified in the query's AQ_scope record, and the activities specified 
in the administrative query itself and in its program sequence in 

15 Program_sequence 855 are performed. The activity performed for a given PR 
record in the result set returned by an execution of an administrative query will 
depend on the record's state with regard to that execution; depending on the 
action records that belong to an administrative activity's Administrative activity 
type, performance of the administrative activity may modify the PR record, may 

20 post an activity in PR_activity table 839, may notify interested parties of 
something that has taken place in the process, may generate a report about the 
result set returned by the query, or may take action based on trends. When all of 
this is finished, system 801 updates the current schedule table 823 for the query 
just executed, setting the time for when this query will be executed next. Before 

25 executing the next query, 801 checks whether the configuration has changed 
(decision block 115); the possible results of such a check have already been 
described. 
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Details of configuring Administrative activity types: FIG. 2 

An administrative activity type is configured by associating one or more 
actions defined in action tables 857 with the administrative activity type. In 
flowchart 201, the kinds of actions are represented by blocks in the flowchart. 
5 With regard to a given administrative activity type, there may be any number of 
actions associated with the given administrative activity type, the actions may be 
of any kind, and they may be configured in any order. An action defined by a 
given record in action tables 857 may, however, be associated with only a single 
administrative activity type. 

10 Beginning with block 205, that block represents the configuration of 

notification actions represented by records in PR_notification table 867; block 207 
represents the configuration of actions that set values in PR records; these actions 
are represented by records in AA_set_values table 859, AA_set_dates table 861, 
and AA_set_person table 863. Block 209 represents the configuration of post 

15 activity actions represented by records in AA_post_activities table 865; Block 211, 
finally, represents actions represented by records in AA_exec_report 869. 



Details of configuring administrative queries: FIG. 3 

An administrative query is configured by associating an SQL query, a 
20 scope, a schedule, an Administrative activity type for the initial activity, a 
program sequence of Administrative activity types, a record in AQ_trends table 
879, and a priority with the administrative query. Previously existing SQL 
queries, scopes, schedules, and Administrative activity types may be reused in 
the configuration; the program sequence and the record in AQ_trends table 879 
25 must be defined for the particular administrative query being configured. 
Flowchart 301 shows these operations; they may be performed in any order. 
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Beginning with block 305, that block sets forth the association of the SQL 
query with the administrative query; block 307 sets forth the association of the 
projects that define the administrative query's scope with the administrative 
query; block 309 sets forth the association of a schedule of execution with the 
5 query; block 310 sets forth the association of a record in AQ_trends table 879 
with the administrative query; block 311 sets forth the association of the 
Administrative activity type for the query's initial administrative activity with 
the query; block 313 sets forth the association of a program sequence in 
Program_sequence table 855 with the query; block 315 sets forth the assignment 
10 of the query to a priority group. 

Details of administrative query execution: FIG. 4 

FIG. 4 is a more detailed flowchart 401 of blocks 105 and part of block 113 
of FIG. 1. The part of the flowchart inside the dashed line represents block 105; 
15 the remainder represents block 113. Flowchart 401 shows how system 801 
executes the code of execution module 821 of system 801 to execute an 
administrative query, performs activities associated with the query, and 
schedules the next execution of the administrative query. 

Beginning with start block 403, as set forth there, flowchart 401 may be 
20 entered by the paths indicated by 103, 107, and 121 in FIG. 1 The first step is 
checking current schedule table 823 (block 407) for an administrative query that 
is scheduled to be executed at the current time; if none is found, it takes branch 
409 from decision block 411 to decision block 115 in FIG. 1 to check if the 
configuration has changed. If there is an administrative query to execute at this 
25 time, it takes branch 413 to block 415. 

The first step in that branch (block 415) is to execute the SQL query 
specified in the administrative query's record in Admin_query table 853, limiting 
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the PR records the query is executed on to those specified in the projects 
specified in the administrative query's record scope. If the result set of PR 
records returned by the query is empty (decision block 417), branch 419 is taken: 
the execution of the query is logged in Admin_query_log table 873 (block 433) 
5 and system 801 uses the information contained in the schedule specified in the 
administrative query's record to update the administrative query's record in 
current schedule table 823 with the time of the next execution of the 
administrative query and returns to block 407. 

If the result set is not empty, each PR record in the result set must be 
10 processed and system 801 begins executing loop 425, which gets executed once 
for every PR record in the result set. First, the next PR record in the result set is 
fetched (423); if there are no more PR records in the set (decision block 427), 
branch 429 is taken to branch 419, and processing continues as described above 
for that branch. If there is a PR record to process, branch 431 is taken to FIG. 5. 
15 Since there may be multiple instances of system 801 running on database system 
825, system 801 ensures that the instances have mutually exclusive access to the 
PR record being processed by attempting to lock each PR record it processes at 
the beginning of processing; if the attempt fails, the PR record is not processed as 
described below unless it is again returned by an administrative query. If the 
20 attempt succeeds, the PR record is processed and then unlocked when processing 
is finished. 

Details of the processing of a PR record: FIG. 5 

Processing of a PR record is shown at FIG. 5. As shown, block 537 
25 determines the current record state; the next step (decision block 539) determines 
if the PR record is in the state of First Occurrence; if not, it is in the state of 
Persistent Conditions. As explained above, system 801 determines the state by 
examining the most recent execution record for the administrative query in 
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Admin_query_log 873 and the most recent record for an execution of the 
administrative query with regard to the PR record in AQ_PRJog 875. 

If the PR record is in the state of First Occurrence for that execution of the 
administrative query, system 801 takes branch 543 and performs the 
5 administrative activity whose Administrative activity type is specified in the 
field pr_activity_type of the administrative query's record in Admin_query table 
853. That done, system 801 initializes the Next Sequence Pointer; in a preferred 
embodiment, it is initialized to 1 (545). 

If the PR record is in the state of Persistent Conditions, system 801 takes 
10 branch 541. In that branch, it first evaluates the record in the administrative 
query's program sequence that is specified by the current value of the Next 
Sequence Pointer (block 551) to determine whether an administrative activity 
need be performed regarding the PR record on this execution of the query 
(decision block 555). If none need be performed, branch 558 is taken: a record 
15 for the current execution of the administrative query and the PR record is made 
in AQ_PRJog table 875, setting the date_aq_executed field to the date/ time that 
the given administrative query was executed, and the next execution of loop 425 
begins. 

If the program sequence record specified by the current value of the Next 
20 Sequence Pointer indicates that the administrative activity specified in the 
program sequence record must be performed, system 801 takes branch 556; as set 
forth in block 549, system 801 performs the administrative activity and sets the 
value of the Next Sequence Pointer as indicated in the program sequence record. 
At this point, branch 543 and branch 556 come together; on both branches, the 
25 performed administrative activity is posted in PR_activity table 839 (block 557). 
Next, a record for the current execution of the administrative query, the PR 
record, and the performed administrative activity is made in AQ_PR_log table 
875 (block 559), setting the following fields principal fields in AQ_PR_log table 
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875: admin_query_id, pr_id, date_aq_executed / date_aa_executed, and 
pr_activity_type; after this, the next execution of loop 425 begins. 

Details of the GUI for defining and modifying administrative queries: FIGs. 9-17 

5 As pointed out in the foregoing, system 801 is highly configurable but 

limits the configurability so that it can be safely done by non-technical users of 
system 801. One reason for this combination of configurability and safety is the 
fact that database tables are used to determine the behavior of system 801. 
Consequently, the data base system's tools can be used to configure the system, 
10 while the database system's access controls can be used to limit the degrees of 
configurability permitted to different users of the system. Another reason for the 
combination of configurability and safety in system 801 is the GUI which non- 
technical users of the system use to define and modify administrative queries. 
This GUI will be disclosed in detail in the following. 

15 

Defining administrative queries: FIGs. 9 and 17 

As shown at 853 in FIG. 6, and explained in detail in the foregoing, an 
administrative query has a query, a scope of PR records 833 that the query will 
be performed on, a schedule indicating when it will be performed, and an 

20 administrative activity type that specifies one or more actions that will be taken 
on PR records 833 returned by an execution of the query. An administrative 
query may also have a program sequence 855 of administrative activities that are 
performed in various states of a given PR record with regard to executions of the 
query that return the PR record. Thus, in order to define an administrative 

25 query, one must either define its parts or choose already-defined parts. The 
same goes for modifications of existing administrative queries. 
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The top-level window of the GUI for defining or modifying administrative 
queries in a presently-preferred embodiment is shown at FIG. 9. Window 901 
has a number of buttons which, when clicked on, give the user access to further 
windows for defining administrative queries and their parts. Thus, button 903 
5 gives access to windows for defining the queries themselves, button 909 gives 
access to windows for defining administrative activities, button 907 gives access 
to windows for scheduling administrative queries, and button 911 gives access to 
windows for defining the scope of the administrative query. 

10 FIG. 17 shows the window 1701 that appears when button 903 is clicked 

on. There is an entry 1702 in the window for each administrative query 
presently defined in system 801; each entry has six fields. Field 1703 contains the 
name of the query executed by the administrative query; field 1705 contains the 
name of the initial administrative activity executed by the administrative query 

15 on PR records returned by the query; field 1707 contains the name of the 
administrative query's scope; field 1709 contains the name of the administrative 
query's schedule; field 1711 contains the administrative query's priority; field 
1713, finally, indicates whether there is a program sequence associated with the 
administrative query, and if so, how many entries there are in the program 

20 sequence. With fields 1703 through 1709, the user may either type the requisite 
name into the field or type an *, at which point, a search window appears which 
permits the user to search for the desired component. The user may select an 
administrative query by selecting a row 1702. When a row is selected, button 
1712 permits the user to insert a row for a new administrative query at that point 

25 in window 1701; button 1714 permits the user to delete one or more selected 
rows; button 1715 permits the user to view and modify a selected query's 
schedule; button 1717 permits the user to view and modify a selected query's 
scope; program button 1719, finally, permits the user to view and modify a 
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selected administrative query's program sequence. Of course, not all users may 
have the access privileges necessary to use given ones of these buttons. The 
effect of defining a new administrative query, modifying an existing 
administrative query, or deleting an administrative query is of course to add a 
5 new record to admin_query table 853, modify an existing record in table 853, or 
delete a record from the table. 

Window 1721 is the window that appears when the user clicks on 
program button 1719. Each row 1723 in window 1721 specifies an entry in the 

10 program sequence for the selected administrative query; the fields are the 
following: field 1725 specifies the sequence number of the program sequence 
entry ; field 1727 specifies the administrative activity to be performed; field 1729 
specifies what to do after the administrative activity specified in the entry has 
been executed, and field 1731 specifies a time interval which must pass before the 

15 given entry should be considered. As already explained in detail in the 
discussion of program_sequence table 855 above, in the preferred embodiment 
there are three choices for program control: continue, i.e., continuing to perform 
the administrative activity specified in row 1723; next, i.e., performing the 
administrative activity with the next sequence number; and stop, i.e., performing 

20 no further administrative activities for the given administrative query. A user 
may of course use window 1721 to add, delete, or modify the program sequence; 
the changes made are retained in Program_sequence table 855. 

Defining scopes for administrative queries: FIG. 10 

25 FIG 10 shows the windows 1001 and 1009 involved in defining or 

modifying a scope. A given scope may of course be used in many administrative 
queries. Screen 1001 lists the presently-defined scopes. This window may be 
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reached by clicking on scope button 1717 in window 1701 or clicking on scope 
button 911 in window 901. Each scope has an entry 1005 with the scope's name 
and the number of projects included in the scope. To define a new scope, the 
user clicks on the insert button and adds the scope's name to the list. To delete a 
scope, the user selects a scope and clicks on the delete button. To see or modify 
the projects in the scope, the user selects the scope and clicks on details button 
1007; thereupon, window 1009 appears. Window 1009 has an entry 1010 for each 
project currently defined in project table 831. An entry 1010 has three fields: the 
division's name, specifying a record in Division table 829 (1011), the project's 
name (1012), specifying a record table project table 831, and whether the project 
in the specific division is included in the scope selected in window 1001 (1013). 
A project may of course be added to or removed from the scope by clicking on 
the check box in field 1013 in the project's row 1010. Changes made in tables 
1001 and 1009 are reflected in AQ_scope table 849 and in the scope specified in 
the administrative query's record in Admin_query 853. Note: the specific names 
given for records in the division table 829 and project table 831 is configurable as 
well; in the specific example of window 1009, a record in the division table 829 is 
named // Department ,/ , and a record in the project table is named "Record Type", 
another example would be "Location" and "Work Area", etc. ' 

Defining schedules for administrative queries: FIG. 11 

The graphical user interface employs windows 1101 and 1109 to define 
schedules for administrative queries. A given schedule may of course be used by 
many administrative queries. These windows are in general similar to those of 
FIG. 10. Window 1101 may be reached from schedule buttons 907 and 1715 in 
windows 901 and 1701. Window 1101 lists the existing schedules and permits 
the user to define new ones. Each row 1103 has two fields: field 1104, which 
contains the schedule's name, and field 1105, which indicates how many entries 
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there are in the detailed description of the schedule. To define a new schedule, 
the user clicks on the insert button and inputs a name for the schedule into field 
1104. To delete a schedule, the user selects a row 1103 and clicks on the delete 
button. To see the detail for a schedule, the user selects the schedule's entry 1103 
5 and then clicks on details button 1107. Thereupon, window 1109 appears. 
Window 1109 has a row 1111 for each day of the week, and the user may specify 
for each day the start time and the end time for scheduling and the time interval 
between one execution of the query and the next. Changes made to windows 
1101 and 1109 are preserved in AQ_schedule table 851, AQ_schedule_detail table 
10 851, and in the relationship between an administrative query and an entry in 
ACLschedule_table 851. 



Defining administrative activities: FIG. 12 

The graphical user interface employs the window 1201 shown in FIG. 12 
15 to define administrative activities. Like scopes and schedules, a given 
administrative activity may be shared by many administrative queries. Window 
1201 is reached by clicking on administrative activities button 909 in window 
901. There is a row 1205 for each administrative activity defined in system 801. 
Each row has a field 1203 for the administrative activity's name and fields 1207 
20 through 1213 indicating what kinds of actions the administrative activity has 
associated with it. If an administrative activity has a given kind of action 
associated with it, the box in the corresponding field of the administrative 
activity is checked, indicating this association. To clarify, if for example, the "Set 
Dates" and the "Posting Activities" check boxes for a given administrative 
25 activity are checked, it indicates that the given administrative activity has at least 
one action for setting date values, and at least one action for posting activities. 
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To define an administrative activity, the user clicks on the insert button and 
inputs the new administrative activity's name into the new row 1205. To define 
an action for the new administrative activity, the user clicks on one of buttons 
1215 through 1221 as required for the kind of action being defined. If at least one 
5 action is defined in any of these action types, fields 1207 through 1213 will be 
checked, respectively. Similarly, if the user wishes to view or modify actions of a 
specific kind for a given administrative activity, the user selects the row 1205 for 
the administrative activity and then clicks on a button 1215 through 1221 as 
required for the kind of action. Deletion is done by selecting a row and then 
10 clicking on the delete button. The modifications made using window 1201 are 
preserved in admin_activity_type table 841. 

General techniques used in defining actions 

As indicated in the discussion of action tables 857 above, most actions 
1 5 involve changing one or more values of fields in the PR record upon which the 
action is performed. Such changes of course affect what queries will return the 
PR record, and thus move the PR record through the stages of a process that the 
PR record is an instance of. The manner in which the types of certain fields in 
the PR records are defined greatly increases the ease and safety with which 
20 actions may be defined and modified. Many of these types are defined by 
system 801; others may be defined by users. In both cases, the types are defined 
using the facilities which database system 825 provides for user-defined types. 

Fields with values belonging to ordered sets of values 

25 One way in which types of fields of PR records are defined is by defining 

an ordered set of values which fields of a type may have. For instance, a field in 
a PR record with the name priori ty_type may have a value from the. ordered 
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set of values {low, normal, emergency}. Because the set of values is 
ordered, it is possible to define operations such as incrementing a value in the 
set. If priority has been set to normal, then the result of the operation 
increment (priori ty_type) is emergency. 

5 

Another operation which is possible because a set of values is ordered, is 
selecting the members of the set in rotation. For example, a field in a PR record 
with the name manager may have as its values the names of the managers of the 
process being monitored, for example, {Brown, Gonzalez , Jones , Smith}. 
10 Here, a next operation may be used to rotate the assignment of tasks among the 
managers. With this operation, if managers has been set to Jones, then 

managers := next (managers) 

sets managers to Smith, and a repetition of the operation and assignment sets 
managers to Brown. 

15 

Role fields 

In system 801, fields in a PR record whose values may be ordered lists of names 
of individuals are termed role fields. Roles and the rotation of tasks among the 
individuals belonging to a role are defined in system 801 by two tables in 
20 database system 825, the Project_member table and the AA_role_last_used table. 
The first of these tables defines membership of persons in projects and roles; the 
second keeps track of the last person belonging to a given role to have been given 
a task. 

25 Projectjnember table 

A record in Project_member table looks like this: 
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Projectmember ( 



5 



id 

project__id 
person_rel_id 
person_role_type 
seq_no 

date__updated 
primary key (id) 



NUMBER (12) NOT NULL, 
NUMBER (12) NOT NULL, 
NUMBER (12) NOT NULL, 
NUMBER (6) NOT NULL, 
NUMBER (6) , 



DATE NOT NULL, 



10 



Each record in the Project_member table represents a Project member, i.e., a 
specific person who is a member of a given Project. The Project_member table 
contains the following data fields: (a) id: a unique ID in this table; (b) 
person_reMd: a unique ID of a given person; (c) person_role_type: a unique ID, 

15 specifying a given person role type, e.g., "Dispatcher", "Tier 1 Help Desk", and 
"Authorized Approver", (d) seq_no: a sequence number, which indicates the 
order in which project members with the SAME Person Role get selected 
(assigned), and (e) date_updated: the date and time that this record was last 
updated. The sequence number defines the order in the set of persons belonging 

20 to the role. A given individual may have more than one entry in the 
Project_member_table and thus belong to more than one project. 

AA_role_lastjused 

A record in the AA_role_last_used table looks like this: 
25 AA_roIe_last_used ( 



35 Each record in the AA_role_last_used table is associated with a given 
administrative activity and logs a person ID and a corresponding sequence 
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id 

pr_activity_type 
data_f ield_id 
person_role_type 
person_rel_id 
seq_no 

date_updated 



NUMBER (12) NOT NULL, 
NUMBER (12) NOT NULL, 
NUMBER (12) NOT NULL, 
NUMBER (6) NOT NULL, 
NUMBER (12) NOT NULL, 
NUMBER (6) , 



DATE NOT NULL 
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number which were last used for a given Admin Activity to assign a person 
belonging to the role to a given PR data field. The AA_role_last_used table 
contains the following data fields: (a) id: a unique ID in this table; (b) 
pr_activity_type: an identifier of a record in PR_activity_type table 837 that 

5 represents the activity's PR_activity type; (c) data_fidd_id: a value that specifies 
what field was set with the last execution of the given Admin Activity; (d) 
person_role_type: identifying the person role that was last used when setting the 
given data field, (e) seq_no: identifying a sequence number that was last used 
when setting the given data field, and (f) date_updated: the date and time that 

1 0 this record was last updated. 

Null values for fields 

Fields in PR records may have null values, which makes it possible for an 
action to determine whether a previous action has set the field's value and to 
15 respond accordingly. 

Using values from other fields in the PR records in setting fields 

In many cases, an action sets a given field in a PR record using a value 
from another field in the PR record. The field from which the value being used 
20 comes is called the reference field. The value may be simply copied, but 
generally, an operation is applied to the value and the value as modified by the 
operation is then assigned to the given field in the PR record. For example, if the 
value is one of an ordered set of values, the value from the reference field may be 
incremented before it is assigned to the other field. 

25 

The graphical user interfaces for defining actions in a preferred 
embodiment of system 801 take advantage of all of these characteristics of the 
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fields in PR records to simplify the task of defining actions. In the following, the 
manner in which each type of action is defined will be described in turn. 

Defining AA_$et_value actions: FIG. 13 

5 FIG. 13 shows the graphical user interface for defining an AA_set_value 

action in system 801. These actions set fields in PR records whose values neither 
represent times or dates nor represent persons or roles. The fields' types may be 
defined by system 801 or users of system 801, but the values for each type must 
constitute an ordered set. An example of such a field is a priority field for 

10 which the values may be {low, normal, emergency}. Window 1301 
contains a list of fields in PR records in system 801 that may be set by 
AA_set_value actions. The entry 1302 for each field has the field's name (1303), 
its type (1305), i.e., whether its values may belong to a single type or to more 
than one type, the operation to be performed on the field's value (1307), which is 

15 one of set , increment , or clear, as shown by the drop-down menu at 1311, 
and the value to which the field is to be set (1309), if the set operation is 
specified. Row 1302 thus specifies the set value action as setting the value of the 
field priority to Emergency . The detail of window 1301 at 1310 shows how 
the user may see the available operations by clicking on field 1307 in entry 1302 

20 to get drop-down menu 1311, from which the user can select the desired 
operation. The detail at 1313 shows the window showing the possible values of 
the field priority which appears when the user clicks on field 1309 in row 
1302. The user may select one of the values in the window. Creation or 
modification of an AA_set_value action in window 1301 of course results in the 

25 creation or modification of a record in AA_set_values table 859. As shown by 
this interface, system 801 separates definition of PR records from definition of 
operations on PR records. 
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General characteristics of windows that define actions 

FIG. 13 also shows a number of general characteristics of the windows 
that are used to define actions in a preferred embodiment. There is a window for 
each kind of action, and each window contains a table which has an entry for 
5 every field in any of the PR records defined in system 801 which can be set by the 
kind of action that the window defines. An entry has two parts: the first part, 
30 3 1303, is a field which identifies the field in the PR record which will be 
affected by the action. The second part 1306 is one or more fields that define the 
action to be taken on the field identified by field 1303. What fields are in 1306 
1 0 and how they define the action depend on the kind of action, or put another way, 
on the type of the values which field 1303 may contain. 

When a user selects an administrative activity by selecting a row 1205 in 
FIG. 12 and then clicks on one of the buttons 1215 through 1221, the resulting 

1 5 window displays all of the actions of the type specified by the button which have 
been defined for the selected administrative activity. If an action has been 
defined for the administrative activity for a given field, the fields 1306 in the 
given field's entry contain the specification of the action. If there is no 
specification, no action has been specified. To specify or modify an action for a 

20 given field, one simply specifies or modifies the fields 1306 in the given field's 
entry as required. 

Defining an AA_set_dates action: FIG. 14 

Window 1401 appears when a user clicks on date values button 1217 in 
25 window 1201. Window 1401 has a row 1402 for each time-date field which can 
be set by a set dates action in any PR record. The row has eight fields: field 1403 
which specifies the name of the field to be set; fields 1405-1409, which specify 
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how the field is to be set if it has a null value at the time the action is performed; 
and fields 1411-1413, which specify how the field is to be set if it does not have a 
null value at that time. Time-date fields are set by specifying a reference field, 
which is another time-date field in the PR record the action is being performed 
on, and an operation to be performed on the time-date field. Taking fields 1405- 
1409 for the case when the field being set has a null value as an example, field 
1405 specifies the name of the reference field; as shown in the detail at 1414, it 
may be set from a drop-do'wn menu 1417 which becomes visible when the user 
clicks on field 44051415. The reference fields also include a built-in system 
reference field whose value is always the current time when the action is being 
taken. The fields 1407 and 1409 define the manner in which the time-date value 
from the reference field is to be modified to make the value which the field to be 
set is to receive. Field 1407 indicates the value to be added or subtracted from 
the value of the reference field and field 1409 specifies the time units, i.e., hours, 
minutes, days, weeks, as shown at 1423 in detail s 1418 and 1422. As shown A 
number of time units is entered at 1421 and at 1423, the time units may be 
selected from a drop-down menu. Also shown in detail 1422 is days rule field 
1412, which indicates at 1425 whether the time is to be calculated in terms of 
business days or calendar days. 

Row 1424 in detail 1422 shows a complete definition of how an 
AA_set_dates action is to set a date: the date due field is to be set when it has a 
null value by using the date created field as a reference field and adding 30 
calendar days to it, as specified in drop-down menu 1423 and at 1425. As is 
apparent from window 1401, setting a field that is already set when an action 
occurs may be done by setting fields 1411 and 1413 as just described for fields 
1403-1409. If an action needs to respond both to a null value and to a non-null 
value in the field being set, values to which the field is to be set may be specified 
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for both the null value and the non-null value cases. The AA_set_dates action 
defined in window 1401 is of course preserved by adding a record to or 
modifying an existing record in AA_set_dates table 861. 

5 Defining an AA_set_person action: FIG. 15 

Window 1501 is the window that appears when a user clicks on person 
values button 1219. Each row 1513 in window 1501 represents a PR field whose 
value is either null or a value representing a given person. As with window 
1301, there is a field for the name of the PR field being set (1503) and then two 

10 sets of fields: one, fields 1505 and 1507, for the case where the field being set has 
a null value at the time the activity is performed, and the other, fields 1509 and 
1511 for the case where the field being set does not have a null value. Again, 
both sets of fields may be defined for a single set_person action. In both sets of 
fields, one of the fields (1505, 1509) permits the field to be set directly to a value 

1 5 which represents a given person or from a reference field whose value represents 
a given person, while the other of the fields (1507, 1511) permits the field to be set 
using a value representing the next person specified for a given role at the time 
the action is performed. As shown at 1515, a role may be selected from a list of 
roles that have been defined in system 801. A direct specification of a person's 

20 name is shown at 1517; if the user enters a * in either field 1505 or 1509, a list of 
the people who are known to system 801 appears and the user may select a name 
from the list; if the user clicks on either field 1505 or 1507, a drop-down menu of 
reference fields appears. Results of the action definition or modification made 
using window 1501 are of course retained in an entry in AA_set_person field 863. 

25 

Defining an AA_post_activities action: FIG. 16 



70 



spartaO 1.005 



When a user clicks on activities button 1221 of FIG. 12, window 1601 
appears. In this window, the user can define an AA_post_activities action. The 
result of such an action is not the modification of a PR record returned by the 
administrative query, but rather the posting of a record in PR_activity table 839 
5 indicating an activity performed automatically, as a consequence of performing 
the given administrative activity or an activity which is automatically scheduled 
to be performed by a given person. The record in this table simply indicates 
whether the activity is to be performed or scheduled to be performed. 

10 There is a row 1602 in window 1601 for each non-administrative 

PR_activity_type in PR_activity Jype table 837. The name of the activity appears 
in field 1604; field 1603 specifies the posting mode, i.e., whether the record 
indicates simply that the activity is to be performed, or whether it is scheduled. 
If the user clicks on field 1603, a drop down menu with the possibilities appears. 

15 If the user selects the scheduled posting mode, fields 1605 through 1607 are used 
to specify the scheduled time in the same fashion as was explained with regard 
to fields 1405 through 1409 of FIG. 14. Field 1605 specifies the field in the PR 
record which is to be used as the reference field to compute the schedule; the 
fields labeled by 1607 indicate how the scheduled date is to be computed. Fields 

20 1609 and 1611 offer two mutually-exclusive ways of specifying the person to 
perform the activity. Field 1609 specifies it by using a reference field with a 
person value in the PR record; the reference field may of course have a role type, 
with the value of the person being that currently specified for the role. Field 1611 
specifies the person directly; in both cases, drop-down lists provide possibilities 

25 the user can choose from. When system 801 processes a PR record returned by 
an administrative query, it selects person values for fields of the role type before 
it does any other processing; system 801 thus guarantees that the tasks being 
posted by AA_post_activities actions will be evenly distributed among the 
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15 



persons who are to do them. An entry 1602 for a completely-defined 
AA_post_activity is shown at 1613. The activity is Begin Audit, which is a 
scheduled activity that is to be performed within two days of the date-time at 
which the administrative activity that performs the action is executed, using 
calendar reckoning. As shown at 1615, T the audit is to be done by the person 
specified by the value of the field "Contact" in the PR record with regard to 
which the action was performed at the time the action was performed. The date 
reference field specified at 1614 for this example is the built-in system date 
reference field discussed with regard to set date actions. When a post activity 
action is defined or modified using window, the defined or modified action is 
preserved in AA_post_activities table 865. Another example would be "Ship 
Order", an activity to be performed 2 days after an order has been received, 
using a "Date Received Order" PR field as a reference, instead of the system date 
reference used in the previous example. 

Using a reference date and or date/ time provides ease of configuration 
and the flexibility to configure system 801 to perform applicable activities based 
on any administrative query criteria, and based as well as on any relevant PR 
data fields. 



20 Dynamic behavior of system 801 

An important characteristic of system 801 is that it does not statically 
define the manner in which it monitors a process. Instead, it is able to 
dynamically adapt the manner in which it monitors the process to events that 
occur in the course of the process. One aspect of system 801 f s dynamic 
25 adaptability is its recognition of the states of First Occurrence and Persistent 
Conditions; another is its ability to define substates of a persistent condition and 
vary the manner in which the process is monitored according to the substate. 
Other aspects of system 801's dynamic adaptability are its use of a reference field 
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in a PR record to obtain a value which can be used in original or modified form 
to set another field in the PR record, its use of types defined as ordered sets of 
values to define escalation operations and to distribute tasks evenly among those 
responsible for them, and its ability to define actions on the basis of whether a 
5 field has already had a value assigned to it. This adaptability is coupled with a 
graphical user interface which defines an action on the basis of the type of field 
the action applies to and can thus structure the window in which the action is 
defined so that the user can easily specify the actions that are relevant to the type 
of the field the action applies to. With this graphical user interface, a non- 
10 technical user of system 101 can easily and safely take full advantage of the 
adaptability. 

Conclusion 

The foregoing Detailed Description has disclosed to those skilled in the 
15 relevant arts how to make and use a process control system that automatically 
provides as much monitoring as is desirable for the processes being controlled 
and has disclosed to those skilled in the relevant arts the best mode presently 
known by the inventors for implementing their process control system. The 
information needed, to do the monitoring, including the queries that perform the 
20 monitoring and the activities to be performed in response to conditions detected 
by the queries, is all contained in tables in a database system. The fact that the 
information is contained in the database tables makes the process control system 
easily and safely configurable and extendable. The ease and safety of 
configurability is further enhanced by the graphical user interface disclosed 
25 herein. 

It will be immediately apparent to those skilled in the relevant arts that 
there are many other ways of implementing the process control system. In 
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particular, there are many ways in which the information needed to do the 
monitoring can be represented in the database system. Moreover, the 
information needed and the manner in which the process control system 
operates will both vary with the kind of process being monitored; in the 
5 preferred embodiment, the processes being monitored are business processes; 
other embodiments may monitor physical processes and the information in the 
database system, the manner in which it is organized, and the manner in which it 
is used to do the monitoring will all vary accordingly. 

The same is the case with regard to the graphical user interface. There are 
many ways in which graphical user interfaces that embody the principles of the 
inventions claimed herein can be implemented; How they look and work in 
detail will depend not only on the purpose for which the process control system 
is being used but also on the underlying graphical user interface tools and 
primitives provided by the system upon which the graphical user interface is 
implemented. Moreover, there are many other ways in which the principles of 
the inventions disclosed herein can be employed. For example, the technique of 
the role field can be used in any case where there is an ordered set of values, as 
can the technique of the increment operation, and reference fields will work as 
sources of values for any kind of field that is being acted on. Detailed operations 
and the details of how they are specified will of course also depend on the kinds 
of values which the field being acted on may have. 

Since that is the case, the Detailed Description is to be regarded as being in 
25 all respects exemplary and not restrictive, and the breadth of the invention 
disclosed herein is to be determined not from the Detailed Description, but rather 
from the claims as interpreted with the full breadth permitted by the patent laws. 

What is claimed is: 
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1 1. A graphical user interface for specifying an action to be performed on a field of a 

2 record when a query with which the action is associated returns the record, 

3 the graphical user interface comprising: 

4 a window containing a table wherein the field has an entry that is selectable by the 

5 user, the entry including 

6 a first field that identifies the field to be acted on; and 

7 one or more action fields that, when the user has selected the entry, the 

8 user may set to specify the action. 

1 2. The graphical user interface set forth in claim 1 wherein: 

2 the identified fiekTs values belong to one of a plurality of types; and 

3 the action fields in the entry are determined by the type of the identified fields 

4 values. 

1 3- The graphical user interface set forth in claim 2 wherein: 

2 the plurality of types include types whose values belong to ordered sets that are 

3 defined in the system in which the graphical user interface is used, types whose values 

4 specify times, and types whose values specify persons. 



1 4. The graphical user interface set forth in claim 1 wherein: 

2 the user may set the action fields to specify that the identified field be cleared. 
1 5. The graphical user interface set forth in claim 1 wherein: 
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the user may set the action fields to specify a value and to specify that the value 
be assigned to the identified field. 



1 6. The graphical user interface set forth in claim 1 wherein: 

2 when the field's entry is selected, the user may set the action fields to specify an 

3 operation by which a new value for the identified field may be computed from a current 

4 value which is the identified field's value when the record is returned. 

1 7. The graphical user interface set forth in claim 6 wherein: 

2 the field's value belongs to an ordered set of values; and 

3 the user may set the action fields to specify an increment operation wherein the 

4 new value is a value that follows the identified field's current value in the ordered set of 

5 values. 



1 8. The graphical user interface set forth in claim 1 wherein: 

2 the identified field may have a null value when the record is returned; and 

3 the user may set the action fields to specify an action that is to be performed when 

4 the identified field has the null value and/or an action that is to be performed when the 

5 identified field does not have the null value. 



1 9. The graphical user interface set forth in claim 1 wherein: 

2 the user may set the action fields to specify a reference field which is another field 

3 in the record and a reference field operation by which a new value for the identified field 
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may be computed from a current value of the reference field which is the value that the 
reference field has when the record is returned. 



1 10. The graphical user interface set forth in claim 9 wherein: 

2 the identified field may have a null value when the record is returned; and 

3 the user may set the action fields to specify a first reference field and a first 

4 reference field operation is to be performed when the identified field has the null value 

5 and/or a second reference field and a second reference field operation that is to be 

6 performed when the identified field does not have the null value. 



1 11. The graphical user interface set forth in claim 9 wherein: 

2 the reference field operation assigns the current value of the reference field to the 

3 identified field. 

1 12. The graphical user interface set forth in claim 9 wherein: 

2 the identified field and the reference field have time values; and 

3 the user may further set the action fields to specify an amount of time by which 

4 the reference field's current value is increased or decreased to compute the new value for 

5 the identified field. 



1 13. The graphical user interface set forth in claim 12 wherein: 

2 the user may further set the action fields to specify the amount of time in one of a 

3 plurality of ways. 
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1 14. The graphical user interface set forth in claim 13 wherein: 

2 one of the plurality of ways is days; and 

3 when days have been specified, the user may further set the action fields to 

4 specify whether the days will be computed as business days or calendar days. 

1 15. The graphical user interface set forth in claim 12 wherein: 

2 one of the reference fields is a field whose value is always set to the current time 

3 when the query returns the record. 



1 16. The graphical user interface set forth in claim 1 wherein: 

2 the identified field has a person value; and 

3 the user may set the action fields to specify a role reference field from which a 

4 new person value for the identified field may be obtained, the role reference field 

5 referring to an ordered set of person values wherein one of the person values is a last- 

6 used person value and the role reference field obtaining the next person value following 

7 the last-used person value at the time the record is returned as the new person value for 

8 the identified field. 



1 17. The graphical user interface set forth in claim 16 wherein: 

2 the user may further set the action fields to specify a person reference field that 

3 has a person value, the identified field being set from the value of the person reference 

4 field when the record is returned. 
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18. The graphical user interface set forth in claim 17 wherein: 

another action has been specified which assigns the person reference field a value 
from a role reference field; and 

when the record is returned, actions which assign person fields values from roll 
reference fields are performed prior to other actions. 

19. The graphical user interface set forth in claim 16 wherein: 

the user may further set the action fields to directly specify a person value, the 
identified field being set from the directly-specified person value when the record is 
returned. 
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